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L  INTRODUCTION 

Over  the  last  three  decades,  the  sheer  number  of  computer  and  communications 
systems  in  the  Department  of  Defense  (DoD)  has  increased  dramatically.  Much  of  the 
increase  is  directly  attributable  to  the  rapid  rate  of  technological  change  and  growth  of 
computing  capabilities  since  the  early  1960s.  Unfortunately,  over  these  nearly  thirty 
years,  the  acquisition  of  computer  hardware  and  software  systems  within  DoD  has  been 
plagued  by  long  developmental  and  implementation  time  periods  often  leading  to 
situations  where  a  computer  system  is  technologically  years  out-of-date  before  ever  being 
fielded.  In  addition  to  significant  schedule  delays,  cost  overruns  have  become  the  norm. 
In  the  DoD,  it  is  common  for  software  development  costs  to  exceed  initial  budget 
estimates  by  50-100%  [Ref.  1].  Of  even  greater  concern,  many  of  the  fielded  systems 
were  “stove-pipe”  systems  —  systems  which  performed  a  specific  set  of  tasks  well  but 
were  incapable  of  operating  and  communicating  with  other  computer/communication 
systems. 

Ideally,  a  computer  system  should  perform  a  multitude  of  user  tasks  and  be  able  to 
operate  harmoniously  with  other  systems.  Computer  users  should  not  require  multiple 
computer  systems  to  perform  their  jobs,  yet  this  is  just  the  road  DoD  was  traveling  the 
last  thirty  years  particularly  with  regards  to  tactical  computer  systems.  DoD,  to  their 
credit,  has  been  struggling  with  and  resolving  many  of  these  issues.  The  Global 
Command  and  Control  System  (GCCS)  is  an  excellent  example.  GCCS  incorporated  the 
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functionality  of  many  command  and  control  (C2)  software  systems  and  packaged  them 
under  one  major  software  system.  Information  Technology  for  the  21st  Century  (IT-21)  is 
an  “...effort  to  fundamentally  transform  the  way  the  Department  of  the  Navy  (DON) 
plans  and  budgets  for  information  technology  (IT)  acquisition  -  shifting  from  acquiring 
IT  as  a  centralized,  large-scale  system  to  considering  IT  as  a  disposable  commodity” 
[Ref.  2].  IT-21  initiatives  provide  a  good  foundation  for  the  concept  of  a  single  platform, 
single  operating  system  environment  for  all  DoD  systems.  Moreover,  IT-21  has  also 
gone  so  far  as  to  state  that  Microsoft  Windows  would  be  the  standard  operating  system 
for  all  systems.  IT-21  espouses  many  common  sense  philosophies  but  DoD  has  a  long 
way  to  go  to  implement  these  visions  most  notably  in  the  realm  of  tactical  computer 
systems. 

Given  the  rapid  rate  of  today’s  technological  changes  and  in  an  environment  of 
austere  budgets,  DoD  faces  a  significant  challenge  relating  to  hardware  and  software. 
Recent  technology  advances  have  allowed  for  the  relatively  simple  and  rapid 
development  of  software  applications.  At  the  same  time,  the  capabilities  and  demand  for 
computer  networks  has  dramatically  increased.  At  a  time  when  network  technologies  are 
maturing  and  mobile  computers  (i.e.,  laptops  with  network  access)  are  becoming 
commonplace,  major  tactical  computer  systems  (programs  that  began  prior  to  this 
developmental  age)  are  just  now  being  fielded.  Once  again,  long  developmental  and 
acquisition  processes  have  led  to  the  fielding  of  technologically  antiquated  and  stove-pipe 
style  systems.  In  an  era  where  mobile  computing  is  commonplace,  the  need  for 
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applications  to  reside  on  one  light  weight,  portable  computer  running  one  operating 
system  is  paramount. 

Rapid  Application  Development  (RAD)  is  quickly  becoming  the  favored  process 
for  Win32  software  development  throughout  many  industries.  RAD  is  especially 
meaningful  to  a  DoD  Command,  Control,  Communications,  and  Computers  and 
Intelligence  (C4I)  community  continually  confronted  and  challenged  by  Moore’s  Law 
(which  states  that  the  number  of  transistors  on  a  computer  chip  will  double  every  18 
months  at  the  same  cost)  [Ref.  3].  Unless  DoD  begins  to  accept  and  practice  some  form 
of  rapid  application  development  techniques  they  will  never  get  ahead  of  the  technology 
beast. 

The  use  of  wireless  Local  Area  Networks  (WLANs)  in  the  commercial  industry 
has  blossomed  in  the  past  few  years  and  the  recent  strides  in  protocol  standardization  and 
advancing  capabilities  of  wireless  equipment  have  opened  up  new  possibilities  of  how 
data  communications  can  be  accomplished.  There  is  a  need  for  the  Marine  Corps  to 
evaluate  this  technology  as  an  network  architecture  to  add  robustness  and  increased  data 
throughput  over  and  above  the  current  capabilities  of  the  combat  net  radio  (CNR)  on  the 
battlefield. 

A.  OBJECTIVE 

The  objective  of  this  thesis  is  to  demonstrate  that  wireless  COTS  technologies  and 
COTS  software  development  tools  can  be  used  to  quickly  enhance  the  ability  of  today’s 
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warfighters  to  accomplish  their  mission,  and  should  become  the  accepted  practice  within 
the  DoD,  when  feasible,  not  the  exception.  Specifically,  this  thesis  seeks  to  demonstrate 
the  use  of  COTS  software  developmental  tools  to  “rapidly”  create  a  Win32  fire  support 
planning  application.  Additionally,  this  thesis  seeks  to  demonstrate  the  need  and 
practical  application  of  implementing  the  use  of  WLANs  at  the  Marine  Corps  regiment 
level  and  below  for  tactical  communications. 

B.  RESEARCH  QUESTIONS 

This  research  addresses  the  following  primary  research  questions: 

1.  Can  a  Commercial  Off  The  Shelf  (COTS)  wireless  technology  architecture  be 
implemented  to  increase  the  bandwidth  to  allow  timely  passing  of  data 
intensive  information  at  the  Marine  regiment  level  and  below? 

2.  Can  COTS  software  developmental  tools  be  used  to  produce  software 
applications  to  aid  the  warfighter? 

C.  METHODOLOGY 

The  research  methodology  consisted  of  a  literature  survey  of  both  government 
C4I  publications  and  commercial  industry  documents,  personal  interviews  with 
commercial  industry  representatives  and  military  stakeholders,  and  field  testing  of  both 
the  developed  software  and  COTS  wireless  equipment. 
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1. 


Literature  Review 


A  literature  survey  was  conducted  to  get  background  material  concerning  Marine 
Corps  communications  equipment,  commercial  wireless  equipment,  wireless 
communications  standards,  both  military  and  industrial,  as  well  as  current  and  planned 
command  and  control  systems/platforms. 

2.  Interviews 

Personal,  telephone,  and  E-mail  interviews/discussions  were  conducted  with 
individuals  who  work  in  the  commercial  wireless  industry,  as  well  as  Navy  and  Marine 
Corps  representatives  involved  in  mobile  computing/communications  at  U.S.  Navy  Space 
and  Naval  Warfare  Systems  Center  (SPAWAR),  Marine  Corps  Tactical  Systems  Support 
Activity  (MCTSSA)  and  the  Marine  Corps  Warfighting  Lab  (MCWL).  Without  their 
input,  support,  and  generous  cooperation  this  research  could  not  have  been  completed. 

3.  Field  testing 

Field  toting  of  the  Fire  Support  Planning  System  (FSPS)  program  and  wireless 
equipment  was  conducted  at  Camp  Pendleton,  CA  with  the  support  of  Marines  from  the 
artillery  community  and  MCTSSA.  The  purpose  of  the  field  testing  was  to  get  feedback 
from  the  end  user  on  the  functionality,  usability,  and  responsiveness  of  the  FSPS  program 
and  wireless  equipment. 
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D.  ORGANIZATION 


This  thesis  is  divided  into  six  chapters  which  are  organized  as  follows: 

Chapter  II  provides  an  introduction  to  Rapid  Application  Development  (RAD) 
and  in-depth  section  on  commercial  wireless  technologies  available  today. 

Chapter  III  provides  an  overview  of  the  Marine  Corps  fire  support  and  command 
and  control  systems,  addressing  its  hardware,  software,  communications  architecture,  and 
capabilities  in  its  current  state  as  well  as  the  Marine  Corps’  proposed  future  state. 

Chapter  IV  provides  information  on  the  fire  support  planning  process,  and  a 
detailed  examination  of  the  development  of  our  Fire  Support  Planning  System  (FSPS) 
application  including  concept,  development,  and  framework. 

Chapter  V  explores  our  testing  methodology  of  the  FSPS  application  transmitted 
over  the  current  C2  architecture  as  well  as  commercial  wireless  equipment.  Additionally, 
our  approach  to  gathering  user  feedback  on  the  FSPS  application  will  be  addressed. 

Chapter  VI  discusses  the  results  of  the  field  testing  and  user  feedback  of  the  FSPS 
program. 

Chapter  VII  contains  the  conclusions  and  recommendations  of  this  thesis  and 
describes  some  of  the  further  research  opportunities  in  this  area  of  study. 

E.  EXPECTED  CONTRIBUTIONS  OF  THIS  THESIS 

The  major  contribution  of  this  thesis  is  the  study  of  COTS  development  tools  to 
provide  a  basic  conceptual  framework  for  the  development  of  Win32  compliant 
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applications  capable  of  interacting  with  the  “Command  and  Control  PC”  (C2PC)  software 
program.  Specifically,  the  Fire  Support  Planning  System  (FSPS)  program,  a  proof-of- 
concept  application,  as  version  1.0,  can  then  be  used  as  the  basis  for  future  fire  support 
application  development.  Additionally,  the  study  of  current  wireless  technologies  and 
how  the  use  of  these  technologies  could  enhance  the  capabilities  of  the  Marine  Corps 
tactical  communications  architecture  to  transmit  the  Win32  compliant  applications  is  a 
benefit  of  this  thesis. 
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H.  CORE  TECHNOLOGIES  BACKGROUND 

This  chapter  will  provide  basic  background  information  and  definitions  covering 
rapid  application  development  and  commercial  wireless  technologies. 

A.  RAPID  APPLICATION  DEVELOPMENT  (RAD) 

The  development  of  any  software  application,  be  it  military  or  civilian,  is  a  time 
consuming  and  highly  laborious  process.  Database  Management  Systems  (DBMS)  and 
4th  generation  programming  languages  were  supposed  to  be  the  savior  of  the  development 
manager  [Ref.  4].  This  has  not  been  the  case.  In  the  more  recent  past,  rapidly  improving 
hardware  platforms  and  microprocessors,  decreasing  military  budgets,  DoD  acquisition 
reform,  the  Navy’s  Information  Technology  for  the  21st  century  (IT-21)  initiatives,  and 
the  resulting  change  in  military  doctrine  have  dramatically  affected  the  types  Of 
applications  the  military  requires  and  the  methods  DoD  uses  to  develop  and  acquire 
software.  These  influences  place  tremendous  pressure  on  software  developers  to  get 
quality  applications  into  the  field  faster  and  cheaper  than  ever  before. 

The  traditional  Software  Development  Life  Cycle  (SDLC)  is  a  sequential,  step-at-a- 
time  approach  to  application  development.  SDLC  has  several  phases;  determining 
requirements,  systems  analysis  and  design,  building,  testing,  implementing,  and 
maintenance.  RAD  is  a  software  development  methodology  which  is  intended  to  provide 
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a  higher  quality  application  at  a  much  faster  development  rate  than  the  traditional 
approach  [Ref.  5]. 

The  RAD  methodology  is  designed  to  take  advantage  of  off-the-shelf  software 
development  design  tools.  Development  tools  such  as  Microsoft’s  Visual  Basic  and 
Visual  C++  allow  developers  to  add  new  functionality  to  individual  stand-alone  systems 
or  to  bring  together  systems  which  are  currently  independent  of  each  other  with  a 
common  Graphical  User  Interface  [Ref.  6].  Hence,  these  applications  are  often  referred 
to  as  “gluing  languages.” 

The  RAD  methodology  provides  a  means  for  more  accurately  capturing  user 
requirements  than  SDLC.  RAD  utilizes  interviews  and  user  workshops  to  capture 
requirements;  evolutionary  prototypes  are  then  developed  in  an  iterative  process  which 
includes  refining  data  models,  process  models,  and  object  models  [Ref.  7],  RAD  uses 
tools  that  support  “visual”  development,  creation  of  fake  prototypes  (pure  simulation), 
creation  of  working  prototypes,  multiple  languages,  use  of  reusable  components,  use  of 
standard  APIs,  and  version  control  [Ref.  8]. 

In  essence,  RAD  is  a  more  cyclical  and  evolutionary  process  than  the  SDLC  method. 
RAD  seeks  to  leverage  current  software  development  tools  and  Computer  Aided 
Software  Engineering  (CASE)  tools  coupled  with  close  contact  and  involvement  from  the 
end  users  to  rapidly  develop  and  field  software  applications.  The  RAD  methodology 
seeks  the  “80%  solution”  today  in  lieu  of  the  perfect  solution  too  far  into  the  future  to  be 
of  any  real  value. 
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Within  the  DoD,  software  development  practices  traditionally  followed  the  SDLC 
approach.  Moreover,  the  approach  was  governed  by  military  standards  (MilStd).  The 
most  notable  MilStd  for  software  development  was  MilStd-498,  Software  Development 
and  Documentation  (dated  5  December  1994).  MilStd-498  recognized  three  software 
development  strategies:  The  Waterfall  Method,  The  Incremental  Method,  and  The 
Evolutionary  Method.  All  three  methods  have  their  own  particular  strengths  and 
weaknesses  (a  discussion  of  which  is  beyond  the  scope  of  this  thesis).  However,  these 
established  methodologies  are  all  versions  of  the  traditional  SDLC.  Though  the  methods 
delineated  in  MilStd-498  were  not  mandatory  DoD  requirements,  the  standard  was  state- 
of-the-art  and  accepted  and  used  by  much  of  the  commercial  software  development 
industry.  On  27  May  1998,  DoD  cancelled  MilStd-498  in  lieu  of  the  IEEE  12207 
standard. 

B.  WIRELESS  TECHNOLOGY 

The  purpose  of  this  section  is  to  provide  the  reader  with  a  broad  overview  of  the 
commercial  wireless  technologies  available  today  that  the  Marine  Corps  could  possibly 
take  advantage  of  to  solve  its  communication  problems  at  the  regiment  level  and  below. 
The  focus  of  the  section  will  be  on  wireless  local  area  networks  (WLANs),  their 
characteristics  and  their  capabilities. 
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1. 


Wireless  LAN 


A  WLAN  allows  workstations  to  communicate  with  either  a  wired  network  or 
completely  autonomous  wireless  network,  while  providing  a  user  the  ability  to  transmit 
and  receive  data  in  excess  of  1  Mbps.  A  WLAN  uses  electromagnetic  waves  as  the 
access  medium,  providing  the  user  mobility  and  freedom  from  a  wired  LAN  [Ref.  9]. 

2.  Military  Applications 

The  military  is  focused  on  getting  a  true  common  tactical  picture  (CTP)  of  the 
battlefield.  Realizing  this  goal  will  require  the  passing  of  near  real-time  data  both  to  and 
from  the  lowest  organizational  levels.  The  Marine  Corps  has  the  adequate  bandwidth 
required  to  pass  data-intensive  information  down  to  the  regimental  level.  The  problem 
with  the  Marine  Corps  communications  architecture  is  that  it  does  not  provide  the  needed 
amount  of  bandwidth  below  the  regimental  level.  The  current  architecture,  i.e., 
SINCGARS,  while  able  to  pass  data,  does  so  at  a  very  slow  rate  of  throughput  that  is  not 
adequate  for  future  applications.  A  WLAN  approach  at  the  regiment  level  and  below 
could  possibly  solve  this  growing  problem. 

3.  Benefits  of  a  Wireless  LAN 
a.  Mobility 

The  Marine  Corps  is  a  highly  mobile  fighting  force  that  must  be  able  to 
communicate  with  its  units  while  stationary  or  on  the  move.  A  WLAN  can  provide  access 
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to  real-time  information  to  those  units/individuals  who  cannot  be  hard-wired  to  a 


network. 


b.  Installation  Speed  and  Simplicity 

Marine  units  cannot  afford  to  spend  the  time,  nor  is  it  operationally 
feasible,  to  lay  networking  cable  while  in  the  field.  Installing  a  WLAN  can  be  quick  and 
easy  and  allow  the  Marine  Corps  the  flexibility  of  taking  the  network  wherever  they  go. 

c.  Scalability 

WLANs  are  very  resilient  in  that  they  can  be  built  from  small  workgroup¬ 
like  networks  to  full  scale  internets  tied  into  a  wired  infrastructure  network.  Since 
Marine  Corps  units  are  hierarchical  in  nature  and  varying  in  size,  WLANs  are  perfect  for 
matching  a  topology  to  the  application. 

4.  How  Wireless  LANS  Work 

a.  Spread  Spectrum 

The  term  spread  spectrum  (SS)  describes  a  modulation  technique  which 
makes  the  sacrifice  of  bandwidth  in  order  to  gain  signal-to-noise  performance.  Basically, 
the  SS  system  is  a  system  in  which  the  transmitted  signal  is  spread  over  a  frequency 
much  wider  than  the  minimum  bandwidth  required  to  send  the  signal.  The  fundamental 
premise  is  that,  in  channels  with  narrowband  noise,  increasing  the  transmitted  signal 
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bandwidth  results  in  an  increased  probability  that  the  received  information  will  be 
correct. 

Spread  spectrum  uses  wide  band,  noise-like  signals.  Because  spread 
spectrum  signals  are  noise-like,  they  are  hard  to  detect.  Spread  spectrum  signals  are  also 
hard  to  intercept  or  demodulate.  Further,  spread  spectrum  signals  axe  harder  to  jam 
(interfere  with)  than  narrowband  signals.  These  Low  Probability  of  Intercept  (LPI)  and 
anti-jam  (AJ)  features  are  why  the  military  has  used  spread  spectrum  for  so  many  years. 
Spread  spectrum  signals  are  intentionally  made  to  be  of  a  much  wider  band  than  the 
information  they  are  carrying  to  make  them  more  noise-like. 

Spread  spectrum  signals  use  fast  codes  that  run  many  times  the 
information  bandwidth  or  data  rate.  These  special  spreading  codes  are  called  “Pseudo 
Random”  or  “Pseudo  Noise”  codes.  They  are  called  “Pseudo”  because  they  are  not  real 
Gaussian  noise. 

Spread  spectrum  transmitters  use  similar  transmit  power  levels  to 
narrowband  transmitters.  Because  spread  spectrum  signals  are  so  wide,  they  transmit  at  a 
much  lower  spectral  power  density,  measured  in  Watts  per  Hertz,  than  narrowband 
transmitters.  This  lower  transmitted  power  density  characteristic  gives  spread  spectrum  a 
big  plus.  Spread  and  narrow  band  signals  can  occupy  the  same  band,  with  little  or  no 
interference.  This  capability  is  the  main  reason  for  all  the  interest  in  spread  spectrum 
today.  The  actual  signal  spreading  available  in  commercial  WLAN  products  is  achieved 
with  one  of  two  techniques:  frequency  hopping  or  direct  sequence  [Ref.  10].  Currently,  a 
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WLAN  implementing  frequency  hopping  cannot  talk  to  a  WLAN  implementing  direct 
sequence,  and  vice  versa,  due  to  the  different  modulating  schemes. 

(1)  Frequency  Hopping  Spread  Spectrum  (FHSS)  Technology. 
Frequency  hopping  is  a  method  of  transmission  that  uses  many  narrowband  channels 
(multiple  frequencies)  to  transfer  the  information.  The  center  frequency  is  shifted,  or  it 
“hops,”  by  a  pseudo  random  code  synthesizer  in  the  transmitter.  Varying  the 
instantaneous  frequency  results  in  an  output  spectrum  that  is  effectively  spread  over  the 
whole  range  of  frequencies  that  are  generated.  Both  the  transmitter  and  receiver  must 
have  the  same  system  timing  so  that  they  are  both  hopping  to  the  next  frequency  at  the 
same  time  [Ref.  11].  Frequency  hopping  is  depicted  in  Figure  1 . 


Figure  1.  An  Example  of  Frequency  Hopping  Spread  Spectrum  Signal  From  Ref.  [17]. 

(2)  Direct  Sequence  Spread  Spectrum  (DSSS)  Technology. 
Direct  sequence  is  a  method  of  transmission  where  the  carrier  signal  is  multiplied  by  a 
pseudo-noise  (PN)  digital  signal  that  spreads  the  information  over  a  wide  frequency  band. 
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The  resulting  signal  looks  like  a  noise  signal  in  the  frequency  domain,  making  it  hard  for 
anyone  to  detect  the  signal.  The  receiver  must  be  using  the  same  PN  signal,  which  is  then 
multiplied  to  the  received  signal  to  detect  the  original  transmitted  information[Ref.  11]. 

(3)  FHSS  vs.  DSSS.  FHSS  poses  several  advantages  over 
DSSS  technology.  It  has  inherent  immunity  to  narrowband  interference  even  though  it 
operates  in  an  unlicensed  band.  It  also  provides  greater  scalability  features  than  DSSS. 
A  disadvantage  to  FHSS  technology  is  its  inability  for  higher  speed  throughput  in  the  2.4 
GHz  band.  With  the  IEEE  802.11a  extension  slated  for  ratification  in  2001,  products  in 
the  5  GHz  range  will  be  available  from  leading  frequency  hopping  wireless  vendors. 
With  5  GHz-based  radios,  these  manufacturers  will  be  able  to  offer  solutions  in  excess  of 
20  Mbps.  Additionally,  FHSS  systems  have  lower  power  consumption  than  DSSS.  To 
attain  comparable  interference  and  multipath  immunity,  a  direct  sequence  system  draws 
greater  power  than  a  frequency  hopping  system.  Furthermore,  FHSS  products  are 
designed  to  go  through  various  power  management  tiers  ranging  from  transmit/receive  to 
doze  and  sleep  during  a  time  interval  defined  by  the  access  point  (base  station)  [Ref.  27]. 

b.  Protocols 

A  protocol  is  “a  formal  description  of  a  set  of  rules  and  conventions  that 
govern  how  devices  on  a  network  exchange  information  [Ref.  12].”  WLANs  are  a 
relatively  new  technology.  Development  and  support  of  industry  standards  (protocols) 
increases  the  adoption  of  technology.  Standardization  of  the  WLAN  industry  will 
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promote  the  use  of  WLAN  technologies  due  to  greater  customer  acceptance.  This  allows 
customers  the  ability  to  solve  more  of  their  business  problems  with  WLAN  solutions  as 
well  as  adapting  systems  that  allow  freedom  of  choice  from  vendors.  In  the  commercial 
WLAN  industry  the  most  recent  standard  developed  is  the  Institute  of  Electrical  and 
Electronics  Engineers  (IEEE)  802.1 1  standard  of  1997. 

The  IEEE  802. 1 1  standard  is  a  breakthrough  for  the  wireless  industry.  The 
IEEE  is  an  internationally  recognized  standards  setting  body.  By  setting  a  standard, 
vendors  will  work  to  develop  equipment  that  meets  that  standard  allowing 
interoperability  with  other  vendors  equipment.  The  focus  is  on  the  radios  and  networks 
operating  in  the  2.4  GHz  Industrial,  Science,  and  Medical  (ISM)  frequency  band.  The 
standard  specifies  the  workings  of  the  lower  two  layers,  the  Physical  layer  and  the  Data 
Link  layer  (sometimes  called  Media  Access  Control  (MAC)  layer),  of  the  International 
Standards  Organization  (ISO)  Open  Systems  Interconnection  (OSI)  seven-layer  reference 
model.  The  OSI  seven  layer  reference  model  is  depicted  in  Figure  2. 
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Figure  2.  The  OSI  Seven-Layer  Model. 

“The  Physical  Layer  in  any  network  defines  the  modulation  and  signaling 
characteristics  for  the  transmission  of  data”  [Ref.  13].  IEEE  802.11  requires  the  use  of 
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either  of  the  two  modulation  techniques  discussed  earlier  for  radio  frequency  (RF)  in  the 
2.4  -  2.4835  GHz  frequency  band.  FHSS  with  a  data  rate  of  1  Mbps,  or  DSSS  with  a 
data  rate  of  1  Mbps  and  2  Mbps.  Each  type  of  modulation  schemes  has  its  own  unique 
advantages  and  disadvantages  depending  on  the  type  and  topology  of  network,  and 
physical  placement  of  the  network  (indoor  or  outdoor). 

“The  MAC  layer  is  a  set  of  protocols  which  is  responsible  for  maintaining 
order  in  the  use  of  a  shared  medium”  [Ref.  14].  At  the  MAC  layer,  the  802.11  protocol 
uses  a  process  called  Carrier  Sense  Multiple  Access  with  Collision  Avoidance 
(CSMA/CA).  This  protocol  is  similar  to  the  CSMA/CD  (collision  detection)  protocol 
that  is  used  in  wired  ethemet  networks.  CSMA/CD  is  a  communications  protocol  in 
which  nodes  contend  for  a  shared  communications  channel,  and  all  nodes  have  equal 
access  to  the  network.  Simultaneous  transmissions  (which  will  result  in  a  collision) 
results  in  a  random  restart  of  those  transmissions.  CSMA/CA  attempts  to  avoid  these 
collisions  before  they  occur  due  to  their  high  cost  in  a  wireless  environment  [Ref.  14]. 

Collision  avoidance  is  used  in  wireless  networks  because  a  node  that  is 
transmitting  cannot  “hear”  another  node  transmitting  due  to  its  own  signal  drowning  out 
any  incoming  signal”  [Ref.  13].  With  collision  avoidance,  a  node  wanting  to  send  a 
message,  once  it  determines  the  channel  is  clear,  will  transmit  a  request  to  send  (RTS) 
packet  that  includes  the  duration  of  the  message  to  the  destination  node. 
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The  duration  of  the  message  is  known  as  the  network  allocation  vector 
(NAV).  Once  the  destination  node  receives  the  RTS  packet,  it  will  return  a  clear  to  send 
(CTS)  packet  to  the  originating  node,  along  with  the  NAV  notifying  all  other  nodes  to  be 
quite  on  that  channel  for  that  duration.  The  originating  node  then  sends  the  data  packet  to 
the  destination.  The  destination  then  runs  a  cyclical  redundancy  check  (CRC)  to  ensure 
the  packet  was  received  intact.  If  so,  the  destination  node  sends  the  originating  node  an 
acknowledgement  (ACK)  packet.  If  during  the  transmission  the  CTS  packet  is  not 
received,  the  originating  node  assumes  a  collision  has  taken  place  and  starts  the  RTS 
process  over  again  [Ref.  13].  This  RTS,  CTS,  data,  and  ACK  process  helps  alleviate 

f 

what  is  called  the  “hidden  node”  problem  as  seen  in  Figure  3. 


As  depicted,  node  A  can  communicate  with  node  B,  and  node  B  can 
communicate  with  node  C,  but  node  A  cannot  communicate  with  node  C.  In  this  scenario, 
when  node  A  “listens”  on  the  channel  and  finds  it  clear,  node  A  will  send  the  RTS  packet 
to  node  B.  The  fact  is  that  node  C  may  be  transmitting  to  node  B  at  that  same  time. 
Node  B  will  not  return  a  CTS  packet  to  node  A. 
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Security  is  another  feature  that  IEEE  802.11  addresses  at  the  MAC  layer. 
Included  in  the  standard  is  a  form  of  encryption  called  the  Wired  Equivalent  Privacy 
(WEP).  WEP  uses  a  64-bit  seed  key  and  the  RC4  algorithm,  a  widely  used  method  of 
encrypting  bit  streams  over  an  RF  medium.  While  not  as  strong  as  the  military 
communications  security  (COMSEC)  algorithms,  WEP  should  suffice  for  most  civilian 
applications  [Ref.  13]. 

Power  management  of  wireless  data  communications  devices  is  a  very 
important  issue  for  the  mobile  user,  especially  for  the  military.  Batteries  are  not  cheap, 
and  recharging  of  the  batteries  is  not  always  an  option  when  deployed  in  the  field 
environment.  The  802.1 1  standard  provides  the  ability  at  the  MAC  layer  for  the  mobile 
wireless  workstation  to  go  into  a  “sleep  mode,”  or  low  power  setting,  for  a  certain  time 
interval  determined  by  the  base  station  [Ref.  13]. 

The  IEEE  802.11  standard  has  brought  better  interoperability  within  the 
commercial  wireless  industry,  but  there  are  several  issues  from  a  military  aspect  that  the 
standard  does  not  address.  Low  bandwidth  and  high  bit  error  rate  (BER)  communication 
channels  are  common  in  the  military,  and  in  an  attempt  to  address  these  specific  issues, 
the  Department  of  Defense  (DoD)  created  MIL-STD-188-220A,  or  the  military’s 
interoperability  standard  for  digital  message  transfer  device  subsystems  (DMTDs).  This 
MIL-STD  has  been  superceded  by  MIL-STD- 1 88-220B . 

This  military  standard  “addresses  the  communications  protocols  and 
procedures  for  the  exchange  of  information  among  DMTDs,  among  C4I  systems,  and 
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between  DMTDs  and  C4I  systems  participating  in  inter-Service  and  intra-Service  tactical 
networks”  [Ref.  15].  This  standard  concerns  itself  with  the  physical,  data  link,  and 
network  (internet)  layers  of  the  OSI  reference  model.  It  details  mandatory  system 
standards  for  using  DMTDs  in  tactical  digital  communications  systems. 

As  stated  earlier,  IEEE  802.11  utilizes  three  signaling  packets  for  each 
data  packet;  the  request  to  send  (RTS),  the  clear  to  send  (CTS),  and  the  acknowledgment 
(ACK)  to  maintain  transmission  reliability.  This  is  in  addition  to  the  normal  network 
protocol  acknowledgments.  According  to  Martin  Nemzow,  this  scheme  typically  reduces 
"wireless  channel  performance"  by  at  least  50%  due  to  increased  overhead  of  these 
signaling  packets  [Ref.  16]. 

The  MIL-STD-188-220B  protocol  utilizes  a  "Type  1"  acknowledgement 
or  unacknowledgement  to  provide  a  much  more  flexible  degree  of  flow  control. 
Therefore,  bandwidth  utilization  can  be  dramatically  improved  under  optimal  channel 
conditions. 

The  MIL-STD-188-220B  supports  transmissions  in  a  half-duplex  mode 
over  radio,  wire-line,  and  satellite  links;  point-to-point,  multi-point,  relay  or  broadcast 
connectivity  between  stations;  and  forward  error  control  (FEC)  for  maintaining  data 
integrity  over  the  link.  FEC  is  critical  to  the  success  of  the  protocol  over  low  bandwidth, 
high  BER  wireless  channels.  The  IEEE  802.11  standard  does  not  support  FEC.  Aside 
from  the  limited  bandwidth  and  high  BER  already  mentioned,  wireless  networks  have 
high  latencies  and  temporary  disconnects  that  must  be  dealt  with  by  network  protocols 
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and  applications.  One  of  the  major  drawbacks  of  using  the  standard  (wired)  transmission 
control  protocol  (TCP)  to  address  these  issues  is  that  TCP  assumes  all  packet  losses  over 
a  network  are  due  to  network  congestion.  To  alleviate  this  problem,  TCP  drops  its 
transmission  windows  size  before  retransmitting  packets  resulting  in  an  unnecessary 
reduction  in  the  utilization  of  channel  bandwidth.  This  also  results  in  yielding  poor 
throughput  and  very  high  latencies.  Using  FEC  with  wireless  networks  can  resolve  some 
of  the  bit  errors  before  they  can  become  a  serious  problem.  [Ref.  15] 

MIL-STD-188-220B  uses  the  Extended  Golay  (24,  12,  8)  coding 
algorithm  as  its  method  for  forward  error  control.  This  allows  the  receiver  to  detect  and 
automatically  correct  errors  in  a  received  block  of  information.  When  used  in 
conjunction  with  the  optional  Robust  Communication  Protocol  (RCP),  it  provides  the 
additional  processing  to  aid  the  transfer  of  up  to  67,200  data  symbols  in  a  single 
transmission  with  better  than  a  90%  probability  of  success. 

An  interesting  feature  of  the  MIL-STD-188-220B  protocol  is  the 
incorporation  of  military  communications  security  (COMSEC)  into  the  very  lowest  layer 
within  the  protocol  data  unit  (PDU).  There  are  three  ways  of  applying  COMSEC  to 
PDUs:  the  transmission  frame  structure  includes  either  a  COMSEC  preamble  and 
postamble  wrapped  around  a  synchronization  component  and  the  data  field;  an  embedded 
COMSEC  message  indicator  into  the  synchronization  component  (without  a  preamble, 
but  with  a  postamble);  or  provides  no  COMSEC  whatsoever  (neither  preamble  nor 
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postamble).  The  preamble  and  postamble  are  only  used  when  link  encryption  is  used 
[Ref.  15]. 

Appendix  H  in  the  MIL-STD-188-220B  provides  a  procedure  for  active 
intranet  topology  updates.  The  "intranet"  is  defined  as  all  the  processors  and  CNRs 
within  a  single  transmission  channel.  Within  the  network,  individual  nodes  know  nothing 
about  neighbor  nodes  that  are  more  than  one  hop  away.  Therefore,  they  need  to 
continually  exchange  network  connectivity  information  as  the  physical  topology  changes 
in  the  form  of  a  topology  update  packet.  All  topology  update  packets  are  transmitted 
exclusively  using  a  global  multicast  address  whenever  a  particular  node  detects  either  a 
failed  link,  a  new  link,  or  a  change  in  the  quality  of  the  link  (if  link  costs  are  used). 
Sparse  spanning  trees  are  used  vice  full  spanning  trees  to  build  topology  tables  to  avoid 
the  overhead  of  full  spanning  trees  [Ref.  15]. 

When  nodes  in  an  intranet  need  to  communicate,  but  are  not  close  enough 
to  their  neighbors  to  transmit  or  receive,  intranet  relaying  is  required  to  be  capable  of 
hearing  each  other's  radio  transmissions.  The  MIL-STD-188-220B  protocol  provides  a 
procedure  for  relaying  packets  across  a  CNR  intranet  using  very  efficient  source-directed 
routes.  Source  directed  routing  provides  a  simple  non-dynamic  procedure  for  relaying  a 
packet  from  an  originator  to  one  or  more  destinations.  The  source  calculates  the  path 
through  the  network  to  reach  each  destination,  and  this  route  is  encoded  into  the  intranet 
header.  Paths  along  a  source  directed  route  are  expected  to  never  have  common  nodes 
[Ref.  15]. 
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On  a  multiple-subscriber-access  communications  network,  MIL-STD-188- 
220B  also  provides  for  a  mandatory  net  access  control  (NAC)  algorithm  which  is  used  to 
detect  the  presence  of  active  transmissions.  It  also  provides  a  means  to  preclude  data 
transmissions  from  conflicting  on  the  network  [Ref.  15]. 

c.  Components 

(1)  Wireless  LAN  Adapters.  Wireless  LAN  adapters  allow  end 
users  to  access  the  WLAN.  These  adapters  may  be  implemented  in  the  form  of  PC  Cards, 
formerly  known  as  Personal  Computer  Memory  Card  International  Association 
(PCMCIA)  cards,  in  notebook  or  palmtop  computers,  as  PCI  or  ISA  cards  internally  in  a 
desktop  computer,  or  can  be  devices  that  are  fully  integrated  into  handheld  entry  devices. 
An  antenna  is  built  into  the  structure  of  the  PC  card  so  that  the  computer  can 
communicate  on  the  WLAN.  An  example  of  a  PC  card  can  be  see  in  Figure  4. 


Figure  4.  An  Example  of  a  PC  Card. 


(2)  Access  Point.  An  access  point  (AP)  connects  the  wireless 
network  to  a  wired  network  utilizing  a  standard  ethemet  cable.  It  is  a 
transmitter/receiver,  or  transceiver,  that  all  wireless  devices  communicate  with  to  transmit 
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and  receive  data  to  other  wireless  devices  in  the  WLAN  or  to  the  wired  network  itself. 
The  access  point,  if  it  has  a  detachable  antenna,  is  usually  mounted  high  so  that  a  greater 
radio  coverage  is  obtained,  and  located  in  a  spot  that  is  the  most  feasible  for  all  mobile 
users  to  be  able  to  communicate  with  it.  An  example  of  an  access  point  can  be  seen  in 
Figure  5. 


Figure  5.  An  Example  of  an  Access  Point. 

An  access  point  is  not  required  for  mobile  computers  to 
communicate  with  each  other  on  a  totally  wireless  LAN.  A  configuration  of  this  type  is 
called  an  independent  or  peer-to-peer  WLAN.  Most  WLANs  will  utilize  an  access  point 
to  extend  the  network  and  provide  movement  for  its  mobile  clients  while  still  allowing 
them  access  to  the  wired  network.  A  typical  WLAN  configuration  is  depicted  in  Figure  6. 
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5.  Employment  Considerations 


a.  Range/Coverage 

The  coverage  (range)  obtained  by  the  mobile  clients  depends  on  which 
vendors  equipment  is  employed,  which  type  of  modulation  is  used,  and  the  environment 
that  the  access  point  is  placed  in,  either  outdoor  or  indoor.  Consideration  must  also  be 
given  to  obstructions  in  the  line-of-sight  (LOS)  between  the  mobile  client  and  the  access 
point  that  can  degrade  the  range.  Range  can  be  extended  through  the  use  of  microcells 
where  the  user  can  roam  from  microcell  to  microcell  whose  coverage  overlaps. 
Overlapping  cells  is  depicted  in  Figure  7. 
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b.  Throughput 

Throughput  in  a  wireless  LAN  is  similar  to  that  of  a  wired  LAN  in  that  it 
is  dependent  on  the  type  product  installed  and  the  configuration  utilized.  Other  factors 
that  affect  throughput  in  a  WLAN  are  the  number  of  users  on  a  particular  channel 
(congestion),  possible  bottlenecks  at  the  wired-to-wireless  interface  (access  point), 
bottlenecks  in  the  wired  network  itself,  range,  and  multipath  interference.  The  throughput 
claimed  by  most  vendors  range  from  1  Mbps  up  to  10  Mbps. 

c.  Integrity  and  Reliability 

Wireless  communications  have  been  in  use  for  many  years  in  both  the 
military  and  commercial  industry.  The  WLAN  industry  is  a  growing  field  that  has 
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developed,  and  continue  to  develop  robust  technologies  that  provide  both  integrity  and 
reliability  for  data  communications  to  a  level  comparable  to  a  wired  LAN. 

d.  Interoperability  with  Wired  Infrastructure 

In  order  for  a  WLAN  to  be  truly  successful,  they  must  interoperate 
seamlessly  with  the  wired  LAN  infrastructure.  One  of  the  goals  in  data  communications 
networks  is  to  make  all  the  background  work  that  the  network  does  transparent  to  the 
user.  Great  strides  have  occurred,  through  the  institution  of  industry  standards,  in  making 
the  WLAN  “user  friendly”  so  that  user  will  trust  that  it  will  work.  The  majority  of 
WLAN  systems  today  support  industry  standard  interconnection  protocols  like  the  IEEE 
802.3  (Ethernet)  and  IEEE  802.5  (Token  Ring).  Commercial  vendors  are  adding  support 
for  wireless  clients  through  the  use  of  software  drivers  that  come  with  their  network 
operating  system  (NOS)  so  that  setup  and  configuration  are  relatively  easy.  The  result  is 
that  a  wireless  client  looks  just  like  any  wired  client  to  a  network. 

e.  Interoperability  with  Wireless  Infrastructure 

As  stated  earlier,  vendor  products  using  the  same  modulation  scheme, 
either  FHSS  or  DSSS,  can  communicate  with  one  another  if  they  are  implemented  in  the 
same  way.  One  of  the  goals  of  the  IEEE  802.11  standard  is  to  increase  this 
interoperability  between  vendors  so  that  a  consumer  can  choose  which  product  to 
purchase  based  on  capability,  while  ensuring  that  the  equipment  they  buy  will 
communicate  with  other  WLAN  systems.  For  example,  a  consumer  could  purchase  an 
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access  point  from  one  vendor  and  purchase  PC  cards  from  another  vendor  with  the 
assurance  that  they  will  communicate  properly. 

f  Interference  and  Coexistence 

WLANs  operate  in  the  unlicensed  2.4  GHz  Industrial,  Science,  and 
Medical  (ISM)  frequency  band.  “Unlicensed”  implies  that  other  products  may  transmit 
on  these  same  frequencies  which  could  cause  some  interference  to  a  WLAN.  One  of  the 
products  that  operate  in  this  band  is  a  microwave  oven,  but  most  WLAN  vendors  account 
for  this  interference  in  the  design  of  their  products.  Another  concern  is  that  of  multiple 
WLANs  coexisting  in  the  same  area.  Depending  on  the  vendor  specific  equipment  being 
employed  by  the  multiple  WLANs,  interference  could  exist.  With  the  development  of  the 
IEEE  802.11  standard,  and  all  vendors  working  toward  that  standard,  the  coexistence 
interference  problem  should  decrease. 

g.  Simplicity/Ease  of  Use 

The  ease  of  use  of  a  WLAN  from  a  mobile  client’s  view  has  already  been 
stated,  but  the  simplicity  and  ease  of  use  for  a  network  administrator  should  not  be 
overlooked,  especially  for  the  deployed  military.  Since  it  is  truly  “wireless,”  there  are  no 
cables  to  pull  as  in  a  wired  infrastructure  except  to  the  access  point.  The  mobile  clients 
and  access  points  can  all  be  configured  and/or  troubleshot  prior  to  deployment  to  ensure 
they  can  communicate.  In  a  rapidly  moving  environment  like  that  of  an  infantry  unit,  this 
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time  savings  can  be  crucial  while  allowing  the  seamless  passing  of  information  while  on 
the  move. 

h.  Security 

Security  is  of  paramount  importance  in  military  communications.  Because 
wireless  communications  has  been  so  widely  used  within  the  military,  the  issue  of 
security  has  been  a  design  criterion  for  wireless  equipment  for  quite  a  while.  While  the 
modulation  schemes  and  encryption  algorithms  built  into  WLAN  equipment  do  well  to 
support  must  commercial  applications,  the  military  requires  a  higher  level  of 
communications  security  than  is  provided  by  most  commercial  vendors. 

As  stated  earlier,  the  MIL-STD-188-220B  has  the  capability  of  supporting 
military  communications  security  equipment.  What  has  yet  to  be  accomplished  is  the 
marriage  of  the  military’s  need  for  communication  security  and  the  ease  of  use  of 
commercially  off  the  shelf  (COTS)  WLAN  equipment.  This  could  be  accomplished  by  a 
vendor  including  support  the  188-220B  military  standard,  but  convincing  one  vendor  to 
support  this  standard  would  only  raise  more  interoperability  issues  and  tie  the  military  to 
only  that  vendor’s  products.  The  services  need  to  think  bigger  than  that.  We  need  to 
work  in  conceit  with  the  standards  making  bodies  to  ensure  that  our  needs  are  voiced  so 
that  a  robust  standard  can  be  developed  that  addresses  all  the  issues  that  we  face  in  a 
deployed  tactical  environment.  While  this  is  an  important  topic  that  needs  to  be 
addressed,  it  is  beyond  the  scope  of  this  thesis. 
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The  cost  of  the  components  of  a  WLAN  vary  by  vendor  and  will  probably 
decrease  in  price  as  WLANs  become  more  popular.  Infrastructure  costs  (access  points) 
are  the  largest  costs  to  consider  along  with  any  antenna  enhancements.  An  access  point 
ranges  in  price  from  $1,000  to  $2,000.  A  cost  savings  over  a  wired  LAN  is  the  money 
saved  on  cabling.  Also,  the  timed  involved  in  installing  the  network  must  be  considered 
toward  man  hours  and  overhead.  WLAN  adapters  vary  on  the  type  of  card.  PC  cards 
range  from  $300  to  $1,000  at  the  time  of  this  writing. 

j.  Scalability 

WLANs  can  scale  from  a  small  network  to  a  very  large  ones.  The  area  of 
coverage  can  be  increased  by  adding  more  access  points  to  your  wireless  network.  This 
ease  of  scalability  would  work  well  in  the  overall  network  scheme  the  military  uses  and 
could  enhance  the  ability  of  operating  in  a  joint  environment. 

k.  Battery  Life  for  Mobile  Platforms 

Battery  life  is  a  very  important  issue  for  the  Marine  Corps  infantry  units. 
Batteries  are  not  cheap  and  budgets  are  tight.  The  life  of  the  battery  will  depend  on  the 
amount  of  use  of  the  mobile  computer,  the  types  of  applications  they  run,  and  the  type  of 
protocols  that  are  being  used.  There  is  a  lot  of  academia  research  currently  being  done  on 
enhancing  battery  life  and  creating  energy  efficient  protocols  for  the  mobile  computer. 


Rechargeable  batteries  are  certainly  an  option,  but  power  is  required  for  the  recharger 
which  may  not  be  available  at  the  company  level  and  below  unless  an  AC/DC  adapter  can 
be  configured  for  use  with  a  High  Mobility  Multipurpose  Wheeled  Vehicle  (HMMWV). 
Also,  with  the  feasibility  of  someday  every  Marine  carrying  or  wearing  a  mobile 
computer,  the  logistics  of  managing  and  distributing  the  rechargeable  batteries  must  be 
considered.  When  one  or  two  Marines  in  a  fire  team  needs  batteries,  who  will  provide 
them?  While  this  is  also  an  important  issue,  it  is  beyond  the  scope  of  this  thesis. 
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III.  BACKGROUND  FOR  DEMONSTRATION  APPLICATION 

This  Chapter  will  provide  basic  background  information  and  definitions  regarding 
automated  fire  support  systems,  the  current  software  and  tactical  communications 
architecture  of  a  Marine  infantry  regiment,  and  the  planned  future  Marine  Corps 
communications  architecture. 

A.  AUTOMATED  FIRE  SUPPORT  SYSTEMS  OVERVIEW 

1.  Brief  History  of  Automated  Fire  Support  Systems 

The  fire  support  community  (“artillery  community”)  was  perhaps  the  first  combat 
arm  community  to  explore  automated  command  and  control  systems.  In  1963  the  US 
Army  launched  its  first  effort  toward  automation  with  the  fielding  of  the  Ml  8  Field 
Artillery  Digital  Automatic  Computer  (FADAC).  This  computer  provided  battery-center 
to  center-of-target  technical  solutions  for  artillery  firing  units.  The  FADAC  computer 
system  automated  the  technical  solution  for  placing  artillery  rounds  on  a  given  target,  but 
did  not  address  tactical  fire  support  planning  details.  At  this  time,  only  half  of  the  fire 
support  process  was  automated.  The  other  half,  fire  support  planning,  still  remained 
manual  and  required  voice  communications.  In  1978,  the  Army  began  fielding  Tactical 
Fire  (TACFIRE),  which  automated  the  tactical  fire  control  process.  TACFIRE  was  a  vast 
improvement  for  fire  support  automation  tools  in  that  it  addressed  tactical  artillery  issues: 
The  artillery  community  now  had  computer  systems  for  both  technical  and  tactical  fire 
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support  requirements.  TACFIRE  though,  was  not  without  its  own  problems.  The 
physical  size  of  the  system  was  the  most  pressing  issue,  as  the  system  required  a  5-ton 
truck  for  transportation.  As  technology  developed  in  the  1980’s,  the  TACFIRE  software 
application  was  subsequently  ported  into  smaller  computers.  The  resulting  system  was 
referred  to  as  Lightweight  TACFIRE  and  was  fielded  to  the  Army’s  light  divisions  in  a 
small  desktop-like  computer  designated  as  the  Battlefield  Computer  Terminal  (BCT). 

Though  advanced  for  its  time,  the  TACFIRE  application  had  a  very  convoluted 
and  unfriendly  user  interface.  To  address  these  shortcomings,  the  Army  began  the 
Advanced  Field  Artillery  Tactical  Data  System  (AFATDSj  program.  With  an  urgent 
need  for  a  better  fire  support  computer  system  and  recognizing  that  the  AFATDS 
program  was  behind  schedule,  the  Army  sought  an  interim  solution.  In  response,  the 
Army  began  fielding  the  Initial  Fire  Support  Automation  System  (IFSAS)  in  1993. 

IFSAS  was  literally  nothing  more  than  the  TACFIRE  system  software  ported 
into  a  Lightweight  Computer  Unit  (LCU)  [Ref.  9].  The  LCU  was  the  first  real  attempt  to 
place  a  tactical  software  application  on  a  true  “PC”.  The  LCU  was  a  “hardened”  80486 
computer  with  communication  ports  for  tactical  combat  radios  (today,  the  LCU  also 
incorporates  the  pentium  processor).  As  a  PC,  the  LCU  could  literally  be  loaded  with  a 
variety  of  software  applications.  The  LCU  was  a  huge  improvement  over  the  BCT. 
However,  recognizing  the  limitations  and  convoluted  user  interface  of  IFSAS,  this 
application  was  intended  as  only  an  interim  solution  for  fire  support  automation  prior  to 
the  fielding  of  AFATDS. 
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2.  Current  USMC  Fire  Support  Automation  Systems 

Because  the  U.S.  Marine  Corps  artillery  community  is  relatively  small,  Marine 
artillery  has  traditionally  aligned  itself  with  the  U.S.  Army  artillery  community  for 
doctrine  and  training,  and  additionally  for  hardware/software  program  and  system 
development.  Though  the  Marine  artillery  community  does  not  necessarily  acquire  all 
Army  developed  systems,  the  Marine  Corps  has  yet  to  develop  or  field  any  systems 
created  solely  for  the  Corps.  All  Marine  fire  support  systems  were  initially  designed 
primarily  for  the  Army. 

Today  the  Marine  Corps  artillery  has  “digitized”  nearly  the  entire  fire  support 
process  from  planning  to  execution.  Though  the  Corps’  fire  support  system  has  the 
capability  to  operate  in  a  complete  digital  mode,  voice  communications  and  manual 
procedures  are  still  used  to  a  great  degree,  primarily  because  of  user  interface  and  digital 
communication  difficulties. 

Because  the  types  and  names  of  fire  support  computer  systems  used  since  the  late 
1980s  has  changed  rapidly,  and  to  avoid  confusion,  the  Marine  Corps  uses  a  single 
acronym,  MCFSS  (Marine  Corps  Fire  Support  System),  to  encompass  all  fire  support 
related  computer  systems.  Today,  two  major  systems  comprise  MCFSS:  the  Lightweight 
Computer  Unit  (LCU)  and  the  DMS  (Digital  Messaging  System,  formally  known  as  the 
DCT  or  Digital  Communications  Terminal).  The  LCU,  as  shown  in  Figure  8,  supports 
two  types  of  fire  support  software;  IFSAS  and  the  Battery  Computer  System  (BCS). 
IFSAS  is  used  at  the  artillery/infantry  battalion  level  and  above  for  tactical  fire  support 
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functions  and  BCS  is  used  at  the  artillery  battery  level  for  technical  gunnery 
computations.  The  DMS  is  the  “forward  entry  device”  used  by  forward  observers  to 
input  fire  requests  to  either  IFSAS  or  BCS. 


Figure  8.  Lightweight  Computer  Unit  (LCU). 


Both  IFSAS  and  DMS  have  worked  fairly  well  but  have  their  drawbacks.  First 
and  foremost  the  IFSAS  software  program,  as  previously  discussed,  is  essentially  the 
dated  TACFIRE  software  ported  over  to  a  smaller,  “modem”  computer.  IFSAS  software 
was  not  designed  and  built  from  the  ground  up,  nor  was  it  built  to  improve  user  interfaces 
or  functionality  but  rather  the  software  was  recoded  to  fit  into  a  80486  processor.  The 
IFSAS  application  therefore  maintained  TACFIRE’ s  original  menu-driven  style  interface 
and  did  not  take  advantage  of  available  and  more  user  friendly  windows  style  interfaces. 
Menu  driven  interfaces  are  not  wrong,  or  even  bad  per  se,  but  if  poorly  designed  can  be  a 
chore  for  users  to  negotiate. 
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IFSAS  fits  into  this  poor  design  category.  From  the  user  point  of  view,  the 
interface  is  extremely  convoluted  requiring  extensive  user  experience.  Menu  items  are 
all  pneumonics  which  are  often  not  intuitively  named.  Example  pneumonics  and  their 
English  translation  are  presented  below  in  Table  1 . 


Pneumonic 

English  Translation 

NNFP;RESFU 

Non  Nuclear  Fire  Plan:  Reserve  Firing  Unit 

ATI;TBMOD 

Artillery  Target  Intelligence;  Target 
Buildup  Report 

ATI;COMD 

Artillery  Target  Intelligence;  Command 

SYS;PTM 

System;  Plain  Text  Message 

FM;FOCMD 

Fire  Mission;  Forward  Observer  Command 

Table  1.  IFSAS  Pneumonics. 


Because  of  this  menu  design,  locating  a  desired  input  screen  is  often  a  tedious,  hit 
or  miss  evolution.  Users  not  intimately  familiar  with  the  system  spend  valuable  time 
searching  for  required  screens  with  the  process  outcome  often  resulting  in  tremendous 
user  frustration.  Moreover,  once  the  desired  input  screen  has  been  located,  the  user  is 
presented  with  a  very  busy  input  form. 

Additionally,  the  IFSAS  application  supports  only  limited  mapping  functions. 
While  map  specific  data  is  loaded  into  IFSAS,  the  data  is  used  predominately  by  the 
application  for  computational  purposes.  The  user  is  not  presented  with  a  really  useful 
map  display.  The  user  is  shown  a  gray  screen  with  an  outline  of  the  input  map.  Included 
on  the  “map”  are  targets,  firing  units,  fire  support  coordination  measures,  and  other 
battlefield  symbols.  However,  colors,  contour  lines,  terrain  features,  and  other  items 
associated  with  a  paper  map  are  unavailable.  While  the  user  can  see  the  relative  location 
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of  important  battlefield  symbols,  he  does  not  have  a  true  digitized  map  with  which  he 
can  interact. 

Another  drawback  of  the  LCU/IFSAS  configuration  is  that  only  one  application 
can  be  executed,  namely  IFSAS.  While  running  the  IFSAS  application,  it  is  not  possible 
to  switch  to  other  applications  such  as  a  program  within  the  Microsoft  Office  package 
thus  greatly  diminishing  the  inherent  powers  of  a  80486  or  Pentium  processor. 

Another  major  drawback  of  the  current  MCFSS  hardware/software  systems  is  the 
lack  of  capabilities  and  functions  provided  to  the  forward  observer  (FO)  by  the  DMS. 
This  handheld  entry  device  provides  the  FO  with  an  ability  to  request  fires,  but  provides 
no  ability  to  input  or  view  any  aspect  of  the  fire  support  plan.  Nor  does  the  user  have  a 
digital  map.  All  map  specific  data  must  be  collected  from  a  traditional  paper  map.  The 
DMS  operates  solely  in  the  realm  of  fire  support  execution. 

B.  CURRENT  C2  ARCHITECTURE 

For  the  purpose  of  this  thesis,  we  will  be  looking  at  the  communications 
architecture  at  the  infantry/artillery  regiment  and  below.  The  primary  means  of 
communications  at  the  infantry  regiment  and  below  is  via  the  Single  Channel  Ground  and 
Airborne  Radio  System  (SINCGARS).  Figure  9  depicts  the  notional  communications 
architecture  for  the  Marine  infantry  regiment  and  below. 
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The  SINCGARS  radio  works  in  either  a  single  channel  or  frequency  hopping 
mode.  It  is  a  Very  High  Frequency  (VHF)  Frequency  Modulation  (FM)  radio  that 
operates  in  the  30-88  MHz  range  providing  operation  on  any  of  2320  separate  channels 
with  a  25  KHz  spacing  between  channels.  Capabilities  include  voice,  data,  and  remote 
control  operations.  Additionally,  it  has  dataport  compatibility  with  current  terminal 
devices,  network  synchronization,  and  low  probability  of  intercept/low  probability  of 
detection  (LPI/LPD)  via  spread  spectrum  frequency  hopping. 

The  planning  ranges  for  voice  communications  for  the  radios  are  200  meters  to  10 
kilometers  for  the  manpack  version  (depending  on  power  setting)  and  10-35  kilometers 
(km)  for  the  vehicular,  power-amplified  version.  The  throughput  characteristics  are  75 
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bps  to  16  kbps,  analog  or  digital.  Communications  security  (COMSEC)  is  provided  via  a 
VINSON  device. 

1.  Data  Transfer 

The  planning  ranges  for  data  communications  for  the  manpack  radio  are  600-4800 
bps  at  3-5  km  and  16,000  bps  at  1-3  km  at  high  power.  For  the  vehicular  version  of 
SINCGARS,  data  rates  of  600-2400  bps  can  be  obtained  at  ranges  from  5-25  km,  4800 
bps  for  5-22  km,  and  16,000  bps  for  3-10  km  utilizing  the  power  amplifier.  When 
planning  for  VHF  communications,  non-normal  conditions  such  as  rough  terrain  and  bad 
weather  must  be  considered  as  these  factors  will  affect  communication  ranges. 

2.  SIP 

The  systems  improvement  program,  or  SIP,  is  an  enhancement  to  the  SINCGARS 
radio  to  increase  data  transmissions.  Three  primary  improvements  were  added:  a  packet 
data  mode  for  packet  networks;  a  forward  error  correction  (FEC)  applique;  and  an 
updated  channel  access  protocol  that  optimizes  data  throughput  performance. 

3.  INC 

The  Internet  Controller  (INC)  is  a  software  controlled  communications  processor 
assembly,  consisting  of  one  circuit  card  assembly  mounted  with  the  SINCGARS 
Vehicular  Amplifier/Adapter  assembly  (VAA).  The  INC  is  part  of  the  SINCGARS  SIP 
program.  It  is  a  4-port  data  router:  2  ports  for  operation  with  the  SINCGARS  SIP  radios, 
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1  port  for  operation  with  a  host  computer,  and  1  port  for  operation  with  either  an 
Enhanced  Position  Location  Reporting  System  Radio  Set  (EPLRS  RS),  a  Tactical 
Multinet  Gateway  (TMG),  or  a  second  host  computer.  The  INC  can  be  thought  of  as  a 
router  on  a  card  that  provides  interconnection  between  the  SINCGARS  SIP  radio  and  an 
EPLRS  Very  High  Speed  Integrated  Circuit  (VHSIC).  The  sharing  of  information  that 
will  take  place  between  the  EPLRS  VHSIC  and  the  SINCGARS  SIP  once  EPLRS  is 
fielded  is  illustrated  below  in  Figure  10. 


4.  TCIM 


The  tactical  communications  interface  modem  (TCIM)  is  actually  a  family  of 
tactical  modems  provided  by  Litton  Data  Systems.  The  TCIM  comes  in  three  versions:  an 
internal  PC/AT  card  for  IBM  PC  compatibles;  an  external  hardened  chassis  modem  that 
connects  via  a  small  computer  system  interface  (SCSI)  cable;  and  a  standard  Type  II  PC- 
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Card.  The  TCIM  supports  over  26  communications  protocols  including  TCP/IP,  MIL- 
STD-1 88-220,  X.25,  and  TACFIRE  Combat  Net  Radio  (CNR). 

The  TCIM  interoperates  with  over  37  types  of  joint  military  tactical 
communications  equipment.  Of  special  interest  to  the  Marine  Corps  is  the  SP-TCIM 
which  is  the  removable  Type  II  PC-Card  with  a  capability  throughput  of  2  Mbps.  Several 
Army  units  and  the  AFATDS  program  office  have  had  success  testing  the  SP-TCIM  in  a 
field  environment.  Additionally,  MCTSSA  has  identified  the  SP-TCIM  as  a  potential 
government  off  the  shelf  (GOTS)  replacement  for  the  two-channel  modem  of  the  rugged 
handheld  computer  (RHC)  that  is  currently  being  development  under  the  family  of  Data 
Automated  Communication  Terminal  (DACT)  umbrella. 

C.  CURRENT  INFORMATION  SYSTEMS 

Technological  advances  have  increased  the  number  of  computers  in  homes  and  in 
the  workplace  over  the  last  few  years.  However,  one  workplace  has  remained  relatively 
free  of  computers  until  recently.  These  workplaces  are  the  command  posts  of  the  Marine 
artillery/infantry  regiments  and  below.  Until  the  last  couple  of  years,  the  only  computer 
systems  to  invade  these  spaces  were  those  related  with  fire  support  (i.e.,  IFSAS).  Today 
all  of  that  has  changed  dramatically. 

The  introduction  of  the  Tactical  Combat  Operations  (TCO)  system,  Intelligence 

s 

Analysis  System  (IAS),  Command  and  Control  PC  (C2PC)  software  application,  and 
AFATDS  has  changed  the  face  of  the  traditional  infantry/artillery  combat  operation 
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center  (COC)  altogether.  A  discussion  of  these  systems,  both  hardware  and  software,  is 
important  to  understand  the  impact  not  only  on  the  Marines  using  these  systems,  but  also 
on  the  communications  architecture  they  will  ride  on. 

1.  Tactical  Combat  Operations  (TCO)  Program 

The  TCO  program  was  initiated  to  provide  automation  of  maneuver  command 
and  control  functions.  The  primary  customer  for  TCO  was  the  Marine  infantryman  who 
prior  to  the  inception  of  TCO  had  no  digital  devices  or  computer  C2  tactical  systems  at 
the  regiment  and  below.  TCO  provides  the  warfighter’s  a  common  tactical  picture  of  the 
battlefield.  Originally,  TCO  was  designed  to  operate  in  a  UNIX  environment.  However, 
during  the  acquisition  process  the  program  manager  recognized  that  the  intended  users 
would  not  appreciate  the  UNIX  user-interface  nor  would  they  be  familiar  with  the 
operating  system,  so  the  decision  was  made  to  also  include  the  Windows  family  of 
operating  systems.  Additionally,  for  many  reasons  beyond  the  scope  of  this  thesis,  the 
decision  was  also  made  to  use  the  IBM  Thinkpad©,  a  COTS  product  designated  as  the 
Intelligence  Operations  Workstation  (IOW),  as  the  hardware  platform.  Today,  two 
versions  of  TCO  exist.  The  UNIX  based  system  and  a  Windows  NT  based  system 
utilising  C2PC  as  the  core  software  application.  Now  for  perhaps  the  first  time,  a  tactical 
system  will  operate  in  the  same  operating  system  environment  as  the  familiar  garrison 
systems.  In  reality,  Marines  spend  the  vast  majority  of  their  time  in  a  garrison 
environment  performing  a  variety  of  important  tasks  but  not  tasks  necessarily  associated 
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with  their  particular  combat  specialty.  The  time  Marines  have  to  become  familiar  with 
their  tactical  computer  systems  is  actually  somewhat  limiting.  It  is  therefore 
advantageous  to  have  a  tactical  system  which  uses  a  familiar  operating  system. 

2.  Intelligence  Analysis  Workstation  (IAS) 

The  IAS  deploys  as  either  a  MEF  IAS  or  as  a  single  IAS  laptop  workstation.  The 
MEF  IAS  serves  as  the  hub  of  the  Marine  Air-Ground  Intelligence  System  (MAGIS) 
which  provides  intelligence  functionality  to  the  echelon-tailored  MAGTF  all  source 
intelligence  fusion  centers.  At  the  regimental  level  and  above  the  IAS  suite  consists  of 
two  HP  UNIX  based  computers.  At  the  battalion  level  the  single  IAS  workstations  are 
Microsoft  Windows  NT  based  systems  now  referred  to  as  intelligence  operations 
workstations  (IOWs).  The  IOW  meets  the  hardware  requirements  for  both  the  IAS  and 
TCO  systems. 

3.  C2PC,  the  Core  C2  Software  Application,  Defined 

The  “Command  and  Control  PC”  (C2PC)  software  program,  a  Windows  based 
Command  and  Control  (C2)  system,  began  in  1994  as  an  internal  research  and 
development  project  of  the  Inter-National  Research  Institute  (INRI).  INRI’s  concept  was 
soon  adopted  by  the  Commanding  Officer  of  the  Marine  Corps  Tactical  Systems  Support 
Activity  (MCTSSA).  Today,  the  C2PC  program  is  sponsored  by  both  the  Marine  Corps 
and  the  U.S.  Navy.  Navy  and  Marine  Corps  versions  of  C2PC  are  still 
underdevelopment  by  both  SPAWAR  and  MCTSSA  respectively,  however,  as  approved, 
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versions  are  actively  being  fielded  to  Marine,  Navy,  and  Coast  Guard  units,  as  to  all  U.S. 
military  units  in  Korea. 

The  C2PC  software  application  has  tremendous  potential  to  significantly  increase 
the  number  of  warfighters  who  can  view  a  Common  Tactical  Picture  (CTP)  of  the 
battlefield  as  provided  by  GCCS.  C2PC  is  not  a  new  command  and  control  system,  nor  is 
it  intended  as  a  replacement  for  GCCS  but  rather  it  is  an  effective  and  efficient  method  of 
extending  the  availability  and  functionality  of  GCCS.  Specifically,  C2PC  extends  the 
JMCIS  application  portion  of  GCCS.  The  ultimate  goal  of  the  use  of  C2PC  is  to  deliver 
not  only  a  CTP,  but  also  useful  battlefield  management  tools,  to  as  many  warriors  as 
possible.  C2PC  does  this  in  a  more  efficient  and  cost-effective  manner  all  while 
maintaining  a  simple  yet  robust  graphical  user  interface  of  the  Window’s  family  of 
operating  systems.  In  essence,  C2PC  allows  anyone,  with  the  appropriate  clearance, 
access  to  JMCIS,  does  so  in  the  more  user-friendly  environment  of  Windows  and, 
perhaps  most  importantly,  requires  only  a  relatively  inexpensive  Windows  95/98/NT/CE 
PC  to  operate,  alleviating  the  need  for  expensive  Unix  terminals.  Today,  C2PC  is  the 
backbone  software  application  for  TCO. 

4.  Advanced  Field  Artillery  Tactical  Data  System  (AFATDS) 

AFATDS  will  be  the  next  fire  support  command  and  control  system  fielded  by  the 
Marine  Corps.  The  program  began  as  an  Army  project,  however  in  1990  the  Marine 
Corps  joined  the  program.  Today,  the  Army  is  the  lead  service  for  AFATDS. 
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AFATDS  will  be  an  exponential  improvement  over  IFSAS/TACFIRE.  While  all 
functional  areas  have  been  enhanced  and  improved,  the  greatest  improvement  is  in  the 
area  of  the  user  interface.  Color  screens,  digital  maps  with  terrain  features,  “windows” 
interface  environment  with  mouse  controls  are  just  the  beginnings  of  the  improvements. 
However,  many  significant  problems  remain.  AFATDS  challenges  include: 

1)  Currently  AFATDS  is  not  interoperable  with  the  Joint  Maritime 
Command  Information  System  (JMCIS)  nor  is  it  DII  COE  compliant 

2)  Runs  in  the  UNIX  Operating  System,  while  TCO  is  running  in  Windows 

3)  No  current  support  for  Microsoft  Office  applications 

4)  Unit  cost  $117,000 

5)  Total  weight  of  the  system  intended  for  use  in  a  battalion  COC  is  696 
pounds  (far  from  mobile) 

While  all  of  these  programs/systems  are  worthwhile  and  serve  a  need,  many  of 
these  systems  were  developed  without  considering  interoperability/network  issues.  Not 
all  of  these  systems  use  the  same  operating  systems,  or  the  same  hardware  platforms,  or 
network  protocol  stacks  or  even  similar  message  formats. 

D.  PLANNED  COMMUNICATIONS  ARCHITECTURE 
1.  Tactical  Data  Network  (TDN) 

The  TDN  is  designed  to  augment  the  existing  Marine  Air-Ground  Task  Force 
(MAGTF)  communications  infrastructure  by  interconnecting  gateways  (down  to  the 
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Major  Subordinate  Command)  and  servers  (down  to  the  battalion/squadron  level)  to  form 
the  communications  backbone  for  MAGTF  tactical  data  systems.  TDN  will  provide  the 
functions  of  data  transfer,  IP  routing,  network  management,  and  value  added  services 
such  as  directory  services  and  message  handling.  The  TDN  system  will  connect  via  the 
existing  long-haul  transmission  systems;  switched  telephone  network;  and  single  channel 
radio  nets. 

As  can  be  seen  in  Figure  1 1,  the  connectivity  below  the  regiment  level  is  still  via 
EPLRS  and  SINCGARS  radios  which  will  provide  a  very  limited  throughput  capability. 
Throughput  is  defined  as  the  average  amount  of  data  (per  second)  carried  by  the  system. 


Figure  1 1 .  TDN  Logical  Architecture. 
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2. 


Enhanced  Position  Location  Reporting  System  (EPLRS) 


As  depicted  in  Figure  4,  EPLRS  is  designed  to  be  the  link  for  the  MAGTF  tactical 
data  system  architecture.  EPLRS  will  be  fielded  down  to  the  Marine  Corps  infantry 
company  level  and  is  intended  to  be  the  primary  means  of  secure,  real-time  data 
distribution  for  sensor  to  shooter  links.  EPLRS  is  a  Ultra  High  Frequency  (UHF)  radio 
operating  in  the  420-450  MHz  range.  EPLRS  uses  synchronous  time  division  multiple 
access  (TDMA),  frequency  hopping,  error  correction  coding,  and  embedded  encryption  to 
provide  a  secure  transmission  channel.  EPLRS  is  capable  of  supporting  multiple 
communications  channels  and  has  automatic  relay  capabilities. 

One  of  the  main  characteristics  that  makes  EPLRS  a  valuable  asset  is  its 
capability  to  provide  position/navigation  information  both  horizontally  and  vertically. 
Two  major  drawbacks,  in  the  view  of  the  authors,  are  EPLRS  limiting  data  throughput 
and  the  carrying  weight.  EPLRS  provides  two  types  of  low  data  rate  (LDR)  needlines  up 
to  14,400  bps,  and  three  types  on  high  data  rate  (HDR)  needlines  of  between  50  -  100 
Kbps.  The  authors  believe  that  this  will  not  provide  the  needed  throughput  that  data 
intensive  applications  of  the  future  will  demand.  Additionally,  each  EPLRS  radio  weighs 
17  lbs  or  26  lbs  with  batteries  installed.  The  authors  believe  that  this  amount  of  weight  is 
not  feasible  for  a  Marine  infantryman  to  carry  resulting  in  the  EPLRS  radio  being  always 
tied  to  a  tactical  vehicle. 
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3. 


Data  Automated  Communications  Terminal  (DACT) 


The  DACT  is  a  tactical  battlefield  situational  awareness  system  and 
communications  terminal  designed  for  the  battalion  level  and  below.  It  is  essentially,  a 
sub-notebook  sized,  “rugged”  computer  with  an  internal  GPS  (Global  Positioning  System 
receiver)  and  an  SP-TCIM  for  interface  with  current  combat  net  radios.  Today,  the 
DACT  comes  in  one  variety  known  as  the  “RHC”  or  rugged  handheld  computer.  To 
date,  the  DACT  has  not  been  fielded  to  operational  units.  Though  no  official  decision  has 
been  made,  it  appears  that  future  “DACTs”  will  come  in  an  variety  of  shapes  and  sizes 
varying  from  notebook  size  to  a  palmtop  sized  unit  to  meet  the  variety  of  different  users 
within  a  battalion  organization. 

4.  Near  Term  Digital  Radio  (NTDR) 

The  NTDR  is  an  Army  tactical  radio  that  is  being  developed  for  mobile 
networked  IP  data-only  applications.  It  is  intended  for  use  as  a  backbone  radio  for  the 
Army’s  Tactical  Operations  Center  (TOC)-to-TOC  communications  at  the  Brigade  level 
and  below.  The  NTDR  is  built  to  the  same  form  factor  as  the  EPLRS  radio  and  can  use 
the  EPLRS  installation  kits.  The  NTDR  uses  two  antennas,  one  for  an  embedded  Global 
Positioning  System  (GPS)  receiver  and  one  for  the  UHF  communications  band  (225-450 
MHz). 

SPA  WAR  Systems  Center,  San  Diego  (SSC-SD)  has  been  tasked  by  the  Marine 
Corps  Amphibious  Warfare  Technology  (AWT)  communication  program  office  to 
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investigate  how  the  Joint  Tactical  Radio  System  (JTRS)  can  be  tailored  to  meet  the  needs 
of  present  and  future  wireless  networking  requirements  for  the  Marine  Corps.  JTRS  is 
described  in  the  next  section.  As  a  part  of  this  task,  SSC-SD  is  evaluating  existing 
products  as  an  interim  solution.  This  is  where  the  NTDR  comes  in.  The  NTDR  radios 
are  designed  to  self-organize  into  a  dynamic  two-tiered  network  scheme  of  backbone 
cluster  heads  and  affiliated  cluster  members  as  shown  in  Figure  12. 


Figure  12.  NTDR  Network  Architecture  From  Ref.  [19]. 

Within  the  NTDR  network,  data  is  routed  and  relayed  automatically  between 
users  and  data  can  hop  across  up  to  seven  nodes.  While  roaming,  the  cluster  members  are 
automatically  handed  off  between  the  backbone  cluster  heads.  In  the  event  of  a  cluster 
head  failure,  the  NTDR  architecture  is  self-healing.  The  radios  utilizes  the  Radio  Open 
Shortest  Path  First  (ROSPF)  as  its  routing  protocol  which  eliminates  the  HELLO  protocol 
used  by  the  Open  Shortest  Path  First  (OSPF)  protocol  found  in  traditional  route  discovery 
to  reduce  network  overhead  bandwidth.  NTDR  uses  Carrier  Sense  Multiple 
Access/Collision  Detection  (CSMA/CD)  as  its  radio  frequency  (RF)  channel  access 
protocol  for  data  transmission.  Additionally,  to  minimize  multiple  access  interference, 
NTDR  network  communications  is  further  subdivided  into  three  frequencies:  (1)  control 
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channel  frequency,  (2)  intra-cluster  local  frequency,  and  (3)  inter-cluster  backbone 
frequency. 

With  the  Marine  Corps  deployment  strategies  that  cover  hundreds  of  kilometers  in 
both  land  and  sea  based  operations,  a  networked  communications  architecture  like  the 
NTDR  provides  is  a  necessity  for  these  types  of  operations.  But  in  its  current  state, 
NTDR  does  not  provide  for  all  required  capabilities  the  Marine  Corps  needs.  The 
specific  issues  that  need  to  be  addressed  are  as  follows: 

a)  NTDR  is  programmed  with  a  clear-to-send  (CTS)  timeout  that  limits  its 
operating  range  to  about  20  nmi  between  any  two  radios.  This  distance  needs  to  be 
increased  because  Marines  operate  in  ranges  greater  than  20  nmi. 

b)  Each  NTDR  has  embedded  GPS  capability,  but  this  position/location 
information  is  not  passed  across  the  network  so  that  situational  awareness  applications 
can  use  this  data. 

c)  The  NTDR  currently  uses  FORTEZZA  encryption  that  does  not  meet  the 
military  type  1  COMSEC  required  for  tactical  communications.  A  FORTEZZA 
encryption  card  is  about  the  size  of  a  thick  credit  card  and  when  it  is  inserted  into  a 
workstation  it  is  used  for  user  authentication  and  access  rights  of  the  individual. 

d)  NTDR  has  a  restricted  IP  addressing  scheme  which  does  not  allow  the 
radio’s  IP  address  to  be  changed  to  a  user’s  subnet  address.  Therefore,  in  order  to 
interoperate  with  other  IP  equipment,  the  radio  must  be  connected  to  a  user’s  subnet 
through  a  router.  Currently,  this  is  not  always  possible. 
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e)  The  NTDR  does  not  support  multicasting.  Multicasting  provides  an 
efficient  way  of  disseminating  data  from  a  sender  to  a  group  of  receivers  which  enables 
more  efficient  bandwidth  utilization  on  the  network  [Ref.  19]. 

5.  Joint  Tactical  Radio  System  (JTRS) 

The  JTRS,  while  still  in  the  concept  phase,  is  being  designed  to  be  a  multi¬ 
band/multi-mode  digital  radio  that  will  work  in  all  environment  domains.  The  JTRS 
family  of  radios  will  be  an  open  systems  architecture  that  will  interoperate  with  legacy 
systems  while  being  capable  of  future  technology  insertion.  The  JTRS  is  being  designed 
so  that  users  needing  multiple  paths  for  voice  and/or  data  will  be  served  by  JTRs  that  are 
capable  of  simultaneously  operating  on  multiple  frequency  bands  and  modes  across 
multiple  networks.  The  JTRS  will  automatically  route  data  within  and  between  different 
networks.  Some  of  the  projected  characteristics  are  as  follows: 

a)  Plug  and  play  versatility 

b)  Field-configurable  modular  hardware 

c)  Field-programmable  waveform  software 

d)  Embedded  position  location  with  automatic  situation  awareness  feed  to  the 
network 

e)  Secure  data  network 

f)  Three  or  more  other  networks/modes 

g)  Automatic  local  and  internet  routing 
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h)  Dynamic  networking,  addressing,  and  bandwidth  allocation 

i)  Operates  on-the-move 

A  wide-band  capable  JTR  is  planned  to  be  available  for  fielding  during  Fiscal 
Years  (FY)  2000-2004,  and  a  multi-band  multi-mode  capable  JTR  is  planned  to  be 
available  from  FY  2004-2010  [Ref.  20]. 

E.  THE  FUTURE  COURSE 

A  new  framework  must  be  considered  for  our  tactical  software/hardware  and 
tactical  networks.  The  goal  should  be  that  our  tactical  systems  are  equal  to  our  garrison 
systems.  Whenever  feasible,  service  members  should  not  have  to  learn  a  new  operating 
system  just  for  tactical  systems.  Further,  stove-pipe  style  systems  can  not  be  allowed  to 
exist.  Stove-piped  systems  are  systems  that  were  developed  to  support  a  functional  area, 
but  in  many  instances,  these  systems  would  not  interoperate  with  each  other  allowing  for 
the  passing  of  time  and  mission  critical  data.  Example  stove-piped  systems  for  a  typical 
COC  are  depicted  in  Figure  13.  WWMCCS  was  the  World  Wide  Military  Command  and 
Control  System,  which  has  been  replaced  by  GCCS.  TBMCS  is  the  Theater  Battle 
Management  Core  System,  which  is  an  upgrade  to  the  Contingency  Theater  Automated 
Planning  System  (CTAPS).  TBMCS  is  used  to  create  the  Air  Tasking  Order  (ATO). 
ATLASS  is  the  Asset  Tracking  Logistics  and  Supply  System.  Finally,  an  end  user 
terminal  (i.e.,  a  computer)  must  be  capable  of  running  multiple  applications.  IT-21 
principles  state  that  we  should  drive  everything  into  a  single  PC  and  that  the  operating 
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system  will  be  some  flavor  of  the  Windows  OS.  The  TCO  program  has  started  the 
Marine  Corps  down  this  path. 


Figure  13.  C4I  Stovepipe  Software. 

The  command  and  control  software  application  for  the  TCO  program  is  C2PC. 
Running  on  a  commercial  laptop  provides  a  hardware  environment  which  is  familiar  and 
allows  for  many  other  applications  such  as  the  Microsoft  Office  suite  and  additionally 
provides  for  email  capabilities.  Future  tactical  software  applications,  which  require 
mapping  and  overlay  functions,  should  be  designed  to  “ride  on  top”  of  C2PC.  Figure  14 
is  a  proposed  future  architecture  for  tactical  software. 

In  this  proposed  model,  a  Complete  Instruction  Set  Computing  (CISC)  operating 
system,  such  as  Windows  NT,  will  be  the  standard  OS  for  all  tactical  applications.  At  the 
very  least,  any  tactical  application  should  be  Windows  based.  If  the  software  application 


requires  mapping  information  or  a  common  tactical  picture  (CTP),  then  the  application 
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should  use  C2PC  as  the  base  application  and  “ride  on  top”  of  C2PC.  The  CTP  is  the 
hostile,  neutral,  and  friendly  forces  current,  anticipated,  projected,  and  planned 
disposition  including  amplifying  data,  for  a  single  operation. 

The  Defense  Information  Infrastructure  Common  Operating  Environment  (DII 
COE)  is  a  collection  of  building  blocks  which  form  a  software  backplane.  The  DII  COE 
is  a  layered  software  architecture  consisting  of  three  layers.  The  layers  are:  the  kernel, 
the  infrastructure  services,  and  common  support  applications.  The  common  support 
application  level  provides  for  a  common  data  understanding  or  information  exchange 
interoperability.  This  level  brings  the  capabilities  for  processing  and  displaying  common 
data  formats. 
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IV.  FSPS  APPROACH  AND  IMPLEMENTATION 


A.  INTRODUCTION 

Prior  to  discussing  the  FSPS  developmental  concept,  it  is  important  to  look  at  the 
Marine  Corps  fire  support  process  concepts  and  philosophies  to  get  an  understanding  of 
the  information  flow  between  the  different  units.  Once  this  is  done,  we  will  look  at  FSPS 
and  how  the  program  can  assist  the  users  of  the  program  in  the  execution  of  fire  support 
planning. 

B.  FIRE  SUPPORT  PLANNING 

Fire  support  functions  can  be  divided  into  two  distinct  classes:  fire  support 
planning  and  fire  support  execution.  Fire  support  planning  encompasses  tasks  associated 
with  planning  for  the  potential  use  of  fire  support  assets  (artillery,  mortars,  naval  surface 
fire  support,  and  aircraft  delivered  ordnance).  Fire  support  planning  tasks  for  Marine 
Corps  units  at  the  regiment  level  and  below  include  developing  a  fire  support  plan,  an 
execution  matrix,  an  attack  guidance  matrix,  a  target  list,  and  a  list  of  fire  support 
coordination  measures.  Fire  support  planning  involves  the  “what,”  “where,”  and  “when” 
of  indirect  fires  in  a  future  engagement  and  is  an  integral  part  of  creating  a  combat 
operations  order.  Fire  support  execution,  on  the  other  hand,  involves  requesting  assets  to 
fire  on  a  particular  target  identified  on  the  current  battlefield.  Fire  support  execution  is 
not  covered  in  this  thesis. 
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1. 


Fire  Support  Planning  Cycle 


Like  all  combat  operations  planning,  fire  support  planning  is  a  continuous, 
interactive  and  changing  process.  The  planning  process  involves  nearly  every  echelon  in 
the  warfighting  chain  of  command  and  demonstrates  flexibility  by  allowing  low-level 
input  with  high-level  refinement  and  high-level  fire  support  plan  production.  The  output 
of  the  fire  support  planning  process  is  a  fire  support  plan  which  is  included  as  part  of  a 
combat  operations  order. 

a.  Personnel  in  Fire  Support  Planning  Cycle  (Marine  Regiment  & 
Below) 

Listed  below  are  the  primary  personnel  involved  in  preparing  and 
providing  input  for  the  fire  support  plan. 

*  Regimental  Fire  Support  Coordinator 

*  Battalion  Fire  Support  Coordinator  and  Artillery  Liaison  Officer 

*  Company  Commander  and  Artillery  Forward  Observer 

b.  Fire  Support  Planning  Documents 

The  following  are  the  primary  fire  support  planning  documents: 

*  List  of  T argets  (recommended  targets) 

*  Target  List  (approved  targets) 

*  Fire  Support  Plan 

*  Attack  Guidance  Matrix  (AGM) 


58 


*  Execution  Matrix 

*  Fire  Support  Coordination  Measures  (FSCMs) 
c.  Fire  Support  Planning  Cycle  Diagram 


In  Figure  15  below,  the  fire  support  planning  cycle  is  depicted  including 
the  units  and  personnel  involved,  and  the  actual  information  that  is  passed.  The  fire 
support  planning  cycle  typically  begins  at  the  Company  Commander/FO  level. 
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C.  THE  FIRE  SUPPORT  PLANNING  SYSTEM  (FSPS)  CONCEPT 

1.  Background 

The  fundamental  objective  of  C4I  systems  is  to  get  the  critical  and  relevant 
information  to  the  right  place  at  the  right  time  [Ref.  23].  Moreover,  automated  systems, 
particularly  C2  systems,  should  be  relevant,  technologically  current,  and  most 
importantly,  user-friendly.  To  provide  systems  that  are  technologically  relevant  is  a 
tremendous  challenge  for  both  the  military  and  civilian  sector.  The  civilian  sector  is  fast 
discovering  that  4th  generation  language  COTS  software  development  tools  provide  a 
viable  and  economically  feasible  means  to  achieve  such  ends. 

Two  recently  been  published  documents  describe  a  direction  and  vision  for  future 
DoD  C2  systems.  These  are  the  “C4I  for  the  Warrior”  paper  and  the  Information 
Technology  for  the  21st  Century  (IT-21)  initiatives  originated  by  Admiral  Clemins. 
Though  not  explicitly  stated,  these  documents  provide  tacit  support  for  Win32  compliant 
software  applications  such  as  C2PC.  They  also  indirectly  provide  a  foundation  for  the 
“Fire  Support  Planning  System”  concept.  The  warrior  of  the  future  “needs  a  fused,  real¬ 
time  true  picture  of  the  battlespace  and  the  ability  to  order,  respond  and  coordinate 
vertically  and  horizontally  to  the  degree  necessary  to  prosecute  the  mission  in  that 
battlespace”  [Ref.  24].  Today  our  C2  systems,  specifically  GCCS,  do  not  provide  a 
readily  available  common  operating  picture  for  all  warfighters  at  all  echelons  in  real-time. 
While  the  GCCS  system  is  extremely  capable,  the  fact  remains  that  it  is  only  accessible  to 
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warfighters  on  medium  to  high  level  staffs,  i.e.,  those  with  GCCS  access.  The  grunts  on 
the  “pointy  end  of  the  spear”  simply  do  not  yet  enjoy  the  same  picture  or  battlespace 
awareness. 

IT-21  introduces  concepts  which  depart  from  past  DoD  computer  philosophies 
and  supports  the  C2PC  concept.  IT-21,  among  other  things,  calls  for  a  serious  attempt  to 
drive  everything  to  a  single  PC,  to  use  commercial-off-the-shelf  products  whenever 
feasible  for  both  hardware  and  software,  and  ultimately  to  have  our  garrison  computer 
systems  equal  to  our  tactical  computer  systems  [Ref.  25].  Stated  another  way,  a  service 
member  should  be  using  the  same  operating  system  and  user  interface  whether  behind  a 
desk  in  garrison  or  in  a  foxhole.  An  ultimate  goal  would  be  for  service  members  to  use 
not  only  the  same  operating  system  but  also  the  same  mobile  computer  (hardened  laptop) 
both  in  garrison  and  in  the  field. 

2.  The  Concept 

Believing  that  tactical  computers  can  and  should  be  on  a  similar  hardware 
platform  and  the  same  operating  system  as  garrison  computers,  we  sought  to  develop  a 
fire  support  system  which  would  address  these  requirements.  The  initial  idea  was  to 
develop  a  fire  support  system  which  could  run  on  the  Windows  operating  system  (OS), 
and  present  the  user  with  a  program  with  the  “look  and  feel”  of  other  familiar  windows 
applications.  Additionally,  the  fire  support  system  needed  to  use  C2PC  as  the  mapping 
and  overlay  engine. 
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D.  MCTSSA  PROJECT  REQUIREMENTS 


The  Marine  Corps  Tactical  Systems  Support  Activity  (MCTSSA)  provided  the 
framework  for  the  development  of  the  Fire  Support  Planning  System.  MCTSSA’s 
guidance  was  to  “write  (code)  a  fire  support  module  for  their  existing  Win32  command 
and  control  program  (C2PC)  that  would  manage  target  lists,  targeting  overlays,  and  target 
planning.  Win32  is  Microsoft’s  Windows  32-bit  architecture.  MCTSSA  essentially 
wants  to  port  as  much  functionality  as  possible  from  the  Unix  AFATDS  system  to  Win32 
using  C2PC  as  the  mapping,  database,  and  overlay  engine”  [Ref.  26]. 

1.  Project  Refinement 

Using  this  broad  framework  provided  by  MCTSSA,  we  sought  more  detailed 
specifications  from  the  fire  support  community  at  Fort  Sill,  OK.  Below  are  the  Marine 
Corps  Artillery  Detachment’s  (located  at  the  US  Army’s  Artillery  School  in  Ft.  Sill) 
recommended  functional  areas  for  a  Windows  based  fire  support  system: 

a)  Artillery  Fire  Mission  Processing. 

b)  Mortar  Fire  Mission  Processing. 

c)  Naval  Surface  Fire  Support  Fire  Mission  Processing. 

d)  Battlespace  Geometry  Management. 

e)  Artillery  Target  Intelligence  Interface. 

f)  Survey  Interface  Requirements. 

g)  DASC  Interface  Requirements. 
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h)  Electronic  Warfare  functions. 

i)  Communications  functions. 

j)  Fire  Support  Planning  utilizing  Ground,  Air  and  Naval  assets. 

Each  of  the  above  functional  areas  fit  into  either  the  fire  support  execution  or  fire 
support  planning  category.  With  the  intention  of  designing  a  fire  support  planning 
system,  only  items  (d),  (e)  and  0)  were  considered  for  inclusion  in  our  system. 

a.  Battlespace  Geometry  Management: 

J 

The  system  must  have  the  ability  to  send,  receive,  and,  if  authorized, 
adjust  the  following  coordination  measures: 

•  All  Fire  Support  Coordination  Requirements. 

*  All  Maneuver  Control  Measures. 

•  All  unit  boundaries,  to  include  Fire  Support  Stations  and  Fire  Support 
Areas  as  required  for  Naval  Surface  Fire  Support  platforms. 

*  All  obstacle  plans. 

•  All  Target  Reference  Points. 

b.  Artillery  Target  Intelligence  Interface 

The  system  must  be  able  to  create,  send,  and  receive  the  following  types  of 
artillery  target  intelligence: 

*  High  Payoff  T arget  List. 
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High  Value  Targets. 


*  High  Payoff  Targets. 

*  Attack  Guidance  Matrix. 

*  Target  Selection  Standards. 

c.  Fire  Support  Planning  Utilizing  Ground,  Air,  and  Naval  Assets 

The  system  must  be  capable  of: 

*  Deliberate  fire  support  planning. 

*  Storing/transmitting  fire  plans. 

*  Obtaining  and  submitting  target  nominations  to  higher  headquarters  (HHQ). 

*  Producing:  Target  list  worksheets,  target  overlay  equivalents,  foe  support 
execution  matrix  equivalents,  and  target  bulletins. 

E.  FSPS  DEVELOPMENT  ENVIRONMENT 

The  Fire  Support  Planning  System  was  developed  using  COTS/GOTS 
technologies.  For  the  software  development,  Microsoft’s  Visual  Basic  6.0  was  used  with 
Microsoft’s  Access  97  as  the  database  engine.  Microsoft’s  HTML  Help  Workshop 
application  was  used  to  build  all  help  files.  Additionally,  one  C2PC  Active  X  component 
(PosSelectBtn.ocx)  was  used  to  capture  and  import  grid  coordinates  from  a  digital  C2PC 
map  into  the  FSPS  application. 
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The  RAD  methodology  of  software  development  was  an  essential  element  in  the 
•  creation  of  FSPS.  Within  eight  months,  we  were  able  to  go  from  a  concept  and  user 
requirements  to  a  functional  (although  still  not  perfect)  application.  This  eight  months 
also  included  time  to  learn  the  Visual  Basic  language  and  Integrated  Development 
Environment  (IDE).  The  lesson  learned  from  our  research  in  this  area  is  that  RAD  and 
COTS  applications  provide  a  viable  alternative  to  the  traditional  DoD  software 
development  practices.  RAD  and  COTS  development  tools  allowed  us  to  create  an 
“80%”  solution  today.  Clearly,  this  meets  end  user  needs  better  than  the  perfect  solution 
in  four  or  five  years. 

1.  Assumptions 

The  following  assumptions  were  made  concerning  the  future  operating 
environment  in  which  FSPS  would  reside: 

*  Email  or  FTP  services  would  be  available  to  allow  for  file  transfer. 

*  An  approved  “windows  laptop”  would  be  available. 

*  A  communications  network  would  exist. 

F.  FSPS  APPLICATION  FRAMEWORK 

Conceptually,  our  model  identifies  three  levels  in  the  fire  support  chain  of 
command;  the  forward  observer  (FO)  at  the  company  level,  the  artillery  liaison 
officer/battalion  fire  support  coordinator  (LNO/FSC)  at  the  battalion  level,  and  the  FSC  at 
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the  regimental  level.  The  FSPS  application  is  designed  to  address  fire  support 
requirements  (as  previously  delineated)  at  each  of  these  echelons.  In  FSPS,  these  three 
echelons  are  displayed  as  “profiles.”  The  first  input  screen  a  user  encounters  requests  that 
a  profile  type  be  chosen  as  seen  in  Figure  16. 


Figure  16.  The  User  Profile  Selection  Screen. 


The  functionality  associated  with  each  profile  varies  slightly  based  on  the  user’s 
chosen  profile.  For  instance,  only  the  FSC  has  the  capability  to  publish  the  final  Target 
List.  FOs  and  LNOs  can  input  recommendations  but  cannot  publish  the  approved  Target 
List.  Based  on  the  user’s  profile  selection,  one  of  the  following  screens  in  Figure  17  is 
displayed. 
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«.  LNO  Options 


FSC  Options 


i*.  FO  Options 


LNO  Options 


A  View  Target  list 


CViewT 


C?  Inibafee  Ural  Infemalbn 


Figure  17.  FSPS  Profiles. 


FSPS  Initialization 


Prior  to  using  the  FSPS  application,  a  few  items  must  initially  be  input  from  the 
FSC.  These  items  are  operation  names  or  phases  and  unit  specific  information.  These 
input  selections  are  accessible  from  the  FSC  Options  screen  under  “Initialize  Operation 
Names”  and  “Initialize  Unit  Information.”  A  picture  of  each  if  presented  in  Figure  18. 
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Figure  18.  Initialization  of  Operation  and  Unit  Names. 


.  These  two  options  give  the  senior  fire  support  coordinator  the  ability  to  ensure 
naming  convention  consistency  for  both  unit  and  operation/phase  names.  Since  the  FSC 
will  ultimately  receive  target  nominations  for  a  particular  operation  or  operation  phase 
from  his  subordinates,  it  is  convenient  to  establish  standard  names  for  both  the 
subordinate  units  and  the  particular  operations  to  alleviate  potential  confusion. 
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The  fire  support  coordinator  also  has  the  responsibility  of  assigning  blocks  of 
target  numbers  to  his  subordinates.  In  FSPS,  this  function  can  be  accomplished  via  the 
“Initialize  Unit  Information”  screen.  The  FSC  simply  assigns  the  target  block’s  letter 
designator  and  starting  and  ending  numbers  to  a  particular  unit.  When  the  FO  initializes 
his  FSPS  application  via  the  FO  Setup  Wizard,  his  entire  block  of  target  numbers  is 
automatically  generated. 

2.  Target  Nominations 

Perhaps  the  most  important  portion  of  the  fire  support  planning  process  is  the 
creation,  receipt,  validation,  and  consolidation  of  targets.  Target  nominations  typically 
begin  at  the  lower  levels  and  are  passed  up  the  chain  of  command.  Once  nominations  are 
reviewed,  they  are  either  deleted  or  approved  for  inclusion  in  the  Target  List.  This 
process  is  conducted  at  each  echelon  (see  Figure  15).  Ultimately,  the  senior  fire  support 
Marine  creates  one  “master”  list,  the  Target  List,  which  is  disseminated  back  down  the 
chain  of  command. 

In  FSPS,  targets  are  created  via  the  “Target  Editor”  screen.  This  screen,  presented 
in  Figure  19,  is  available  to  all  three  profiles  with  only  slight  differences  in  functionality. 
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Figure  19.  Target  Editor. 

The  screen  opens  with  the  “Min  Tgt  Information”  tab  in  view.  The  input  boxes 
under  the  “Min  Tgt  Information”  tab  are  typically  the  only  required  information  for  a 
target  nomination.  The  user  adds  a  target  by  clicking  the  “Add  Tgt”  button  provided  on 
the  lower  left  hand  comer  of  the  Target  Editor  screen.  Once  all  target  information  has 
been  entered,  the  user  selects  “Ok.”  The  targets  may  also  be  deleted  via  the  “Delete  Tgt” 
button  or  may  be  changed  by  clicking  on  the  “Edit  Tgt”  button. 

If  desired,  or  required,  the  user  can  input  other  target  related  information  by 
clicking  on  the  “Tgt  Details”  tab.  Additionally,  in  the  right  pane,  a  listing  of  previously 
input  target  numbers,  descriptions,  and  locations  is  provided  to  give  the  user  a  quick 
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snap-shot  of  all  input  targets.  Should  the  user  desire  to  view  the  targets  and  all  of  then- 
associated  details,  the  user  can  click  “List  of  Targets”  under  the  “View”  menu  available 
in  the  main  menu  bar.  When  clicked,  the  screen  presented  in  Figure  20  is  made  available. 


Figure  20.  List  of  Targets. 


Once  the  user  has  input  all  desired  targets,  they  may  be  saved  by  clicking  the 
“save”  icon  or  selecting  “save”  from  the  main  menu  bar.  Once  saved  as  a  .fsp  file,  the 
target  nominations  may  be  forwarded  up  the  chain  of  command  for  additional  processing, 
or  for  viewing  at  a  later  time  be  the  user. 

The  only  differences  between  the  target  editor  screen  for  FO’s  versus  LNO’s  and 
FSC’s  is  the  ability  to  run  the  target  consolidation  screen  and  the  ability  to  create  the  final 
target  list.  LNO’s  and  FSC’s  may  both  run  tire  target  consolidation  function  but  the 
target  list  can  only  be  produced  via  the  FSC’s  target  editor  screen. 
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The  target  consolidation  function  allows  LNO’s  and  FSC’s  to  quickly  ascertain  if 
target  duplications  exist  in  terms  of  location.  If  two  or  more  targets  have  the  same  grid 
location  or  if  they  are  within  a  given  distance  (in  meters,  as  determined  by  the  LNO/FSC) 
from  each  other,  the  LNO  or  FSC  may  choose  to  delete  or  “consolidate”  specific 
nominations.  Figure  21  shows  the  target  consolidation  screen. 


Figure  21.  Target  Consolidation. 


Once  the  FSC  has  received  all  target  nominations  and  conducts  his  own 
consolidation,  the  FSC  may  create  the  target  list  by  selecting  “Add  current  LOT  to  Target 
List”  from  the  main  menu  bar.  After  the  target  list  has  been  created,  it  is  saved  and 
disseminated  down  the  chain  of  command.  Once  received  and  imported,  LNOs  and  FOs 
may  then  view  the  approved  target  list.  An  example  target  list  screen  is  shown  in  Figure 
22.  Within  the  target  list  screen,  users  also  have  the  option  to  view  all  targets  or  they 
may  to  view  targets  based  on  a  given  operation  name. 
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Figure  22.  Target  List. 


3.  Target  Groups  and  Series 

A  target  group  is  defined  as  more  than  one  target  fired  simultaneously,  while  a 
target  series  is  more  than  one  target  fired  in  accordance  with  a  time  schedule.  Target 
groups  and  series  are  typically  created  during  the  target  generation  process.  For  example, 
after  a  FO  selects  a  number  of  targets  for  nomination,  he  often  will  create  a  number  of 
target  groups  and  series  as  well.  Accordingly,  in  FSPS,  these  two  targeting  options  are 
accessed  via  the  Target  Editor  screen.  FSPS  addresses  these  aspects  of  the  targeting 
process  via  the  screens  presented  in  Figures  23  and  24. 
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Figure  23.  Groups. 


4.  Fire  Support  Plan 


The  fire  support  plan  is  produced  by  the  FSC.  The  plan  includes  a  written  portion 
and  three  attachments.  These  attachments  are  the  fire  support  coordination  measures 


(FSCMs),  an  execution  matrix,  and  an  attack  guidance  matrix  (AGM).  In  FSPS,  only 
LNOs  and  FSCs  may  create  or  edit  any  fire  support  plan  document.  FOs  are  restricted  to 
viewing  these  documents. 

The  first  screen  available  through  the  “fire  support  plan”  option  on  either  the 
LNO’s  or  FSC’s  Options  screen  is  presented  in  Figure  25.  Within  the  “fire  support  plan” 
screen  are  three  text  boxes  for  the  FSC  to  write  the  Commander’s  Intent,  Coordinating 
Instructions,  and  Critical  Information  portions  of  the  fire  support  plan.  Additionally,  this 
screen  has  three  buttons  to  access  the  fire  support  plan  attachments. 


Figure  25.  Fire  Support  Plan. 

The  AGM,  presented  in  Figure  26,  is  a  replication  of  the  current  AGM  used  by  the 
1st  Marine  Division  (1st  MarDiv).  This  format  is  not  currently  part  of  the  Marine  Corps’ 
fire  support  doctrine,  but  has  been  used  by  the  1st  Marine  Division  for  the  last  five  years 
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Figure  27.  Execution  Matrix. 


5.  File  Saving  and  Dissemination 


Once  all  pertinent  information  has  been  input,  the  user  saves  the  information  by 
clicking  the  “save”  icon  or  by  selecting  “save”  from  the  “file”  menu  option  on  each 


screen.  The  information  is  saved  with  the  “.fsp”  file  extension  and  is  saved  as  a  tab 
delimited  ASCII  (American  Standard  Code  for  Information  Interchange)  file.  These  files 
may  now  be  exported  up  or  down  the  chain  of  command  and  input  into  the  users  FSPS 
application.  The  files  may  be  delivered  via  a  1  Vi”  floppy  disk,  FTP  (file  transfer 
protocol),  or  as  an  email  attachment. 

6.  Wireless  Implementation 

Once  the  FSPS  files  have  been  saved,  they  need  to  be  disseminated  either  up  or 
down  the  chain  of  command  to  the  designated  recipient.  It  is  the  authors  belief  that  this 
dissemination  should  take  place  over  a  wireless  tactical  network  vice  the  combat  net  radio 
network  currently  in  place.  In  Chapter  V,  a  comparison  of  the  data  transfer  rates  and 
throughput  between  the  two  technologies  will  be  examined. 
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V.  ANALYSIS  AND  FINDINGS 


The  current  software  development  and  communications  architecture  does  not 
work  in  this  data  intensive  age.  Software  development  is  too  slow,  and  the 
communications  equipment  does  not  provide  the  necessary  bandwidth  required.  With 
that,  we  set  out  to  evaluate  the  FSPS  and  wireless  technologies  in  the  tactical  arena  with 
the  aid  of  1 1*  Marines  and  MCTSSA. 

Our  analysis  and  evaluation  was  divided  into  two  areas:  a  limited  usability  study 
of  the  FSPS  application  and  a  more  technical  evaluation  of  file  transfer  over  both  tactical 
radios  and  wireless  equipment. 

A.  USABILITY  STUDY 

1.  Why  Complete  a  Usability  Study? 

One  of  the  most  important  aspects  of  the  RAD  method  of  developing  software  is 
user  feedback.  For  a  software  application  to  be  really  useful,  end  user  input  must  be 
garnered  throughout  the  development  process.  One  advantage  we  had  in  creating  FSPS 
was  that  one  of  the  developers  was  an  artillery  officer  and  therefore  had  personal 
experience  and  technical  knowledge  regarding  many  of  the  user  requirements.  However, 
feedback  from  one  individual  is  not  enough.  We  therefore  sought  responses  from  other 
Marine  artillerymen  concerning  the  design,  “feel,”  and  functionality  of  FSPS. 
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2.  The  Study 


Because  the  main  focus  of  our  research  was  on  the  development  of  the  FSPS 
application  and  the  exploration  of  wireless  technologies,  we  did  not  have  sufficient  time 
or  resources  to  conduct  a  formal  evaluation  of  the  FSPS  application.  Instead,  we  chose  to 
conduct  an  informal  usability  study  which  is  actually  more  appropriate  for  this  stage  of 
the  development  process  [Ref.  28]. 

a.  The  Participants 

The  participants  were  all  Marine  artillerymen  currently  serving  in  the  1st 
Marine  Division  at  Camp  Pendleton,  California.  The  four  participants  were  volunteers 
and  had  a  wide  variety  of  fire  support  experience. 

b.  Participant  Demographics 

*  Major,  12  years  of  service,  currently  serving  as  a  Marine  Regiment  Fire 
Support  Coordinator. 

*  1st  Lieutenant,  3  years  of  service,  currently  serving  as  an  infantry  battalion 
artillery  liaison  officer. 

*  1st  Lieutenant,  3  years  of  service,  currently  serving  as  a  forward  observer. 

*  Sergeant,  8  years  of  service,  currently  serving  as  an  artillery  liaison  chief  for 
an  infantry  battalion. 

c.  Procedures 

All  participants  were  gathered  into  a  room  and  received  an  hour-long 
presentation  on  the  use  of  the  FSPS  application.  Following  the  presentation,  the  users 
were  each  given  a  task  list  and  asked  to  perform  various  fire  planning  operations.  Data 
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was  collected  on  each  task  completed  by  each  participant.  Following  this,  each 
participant  was  asked  to  complete  a  user  feedback  form. 

d.  Task  List/Feedback  Form 

For  this  usability  study,  tasks  were  created  for  Forward  Observers  and  Fire 
Support  Coordinators.  Since  the  Liaison  Officer’s  (LNO)  job  incorporates  portions  of 
both  the  FO  and  FSC  tasks,  this  particular  job  was  not  part  of  the  study.  Following  the 
completion  of  the  task  list,  each  participant  was  asked  to  complete  a  user  feedback  form. 
The  task  lists  and  user  feedback  forms  can  be  found  in  Appendix  A. 

3.  Presentation  of  data 

Below  is  a  compilation  of  all  data  obtained  from  the  questions  on  the  user 
feedback  form. 

1 .  The  concept  of  a  Windows  based  fire  support  planning  tool  is? 

Outstanding  Excellent  Average  Poor  Unacceptable 

□  Outstanding 
B  Excellent 

□  Average 

□  Poor 

B  Unacceptable 

Question  1 

Figure  29.  Question  1. 


81 


2.  As  a  possible  solution,  the  Fire  Support  Planning  System  application  is? 


Outstanding  Excellent  Average  Poor  Unacceptable 


Figure  30.  Question  2. 


3.  What  features  of  the  Fire  Support  Planning  System  did  you  like? 

*  Continuous  update  of  all  units  and  forward  observers  (when  connected  to  a 
TDBM  via  C2PC). 

*  Windows  based  system  with  point  and  click  functionality. 

*  Interface/compatibility  with  TCO. 

*  Easy  initialization. 

*  Fire  planning  is  quicker  from  the  FO  to  the  LNO  and  FSC. 

Equipment  for  FOs,  LNOs,  and  FSC  is  much  smaller  than  current 
computers  (assuming  COTS  notebooks/laptops  are  used). 

*  Simple,  very  easy  to  use.  Eliminates  the  large  number  of  hours  an  operator 
would  have  to  spend  learning  the  program. 

*  Provides  the  ability  to  edit  and  review  input. 

*  Able  to  pass  information  rapidly. 

4.  What  features  of  the  Fire  Support  Planning  System  did  you  dislike? 

*  Menu  bar  icons  and  menu  text  are  not  on  the  same  window/screen. 
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5.  Compared  to  the  automated  fire  support  planning  tools  you  currently  use,  the 
Fire  Support  Planning  System  is? 

Superior  Better  The  Same  As  Worse  Than  Much  Worse  Than 


Figure  31.  Question  5 


6.  Does  the  Fire  Support  Planning  System  application  provide  all  the 
functionality  you  need  to  perform  your  mission? 

Yes  No  If  no,  then  what  else  do  you  need? 

*  Not  compatible  with  the  BCS  (computer  which  computes  technical  firing 
solutions). 

*  Target  information  symbology  is  not  placed  on  the  map  in  C2PC. 

*  Bugs  in  some  of  the  forms. 

*  Needs  to  allow  for  sending  a  fire  mission. 

*  Series  screen  needs  to  be  displayed  in  a  “worksheet”  format. 

4.  Interpretation  of  Data 

Because  this  study  was  a  small,  informal,  and  relatively  unsophisticated  usability 
study,  no  “scientific”  results  can  be  realistically  derived.  However,  a  number  of  useful 
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generalities  can  be  inferred.  First,  the  results  of  questions  1,  2,  3,  and  5  from  the  user 
feedback  form  show  that  potential  users  desire  a  Windows  based  fire  support  tool  and  that 
the  FSPS  application  prototype  is  certainly  a  possible  starting  point  worthy  of  continued 
development.  Second,  question  4  and  general  observations  made  by  the  authors 
highlighted  problem  areas  with  FSPS. 

5.  Discussion 

Based  on  the  results  of  the  usability  study  and  the  authors’  knowledge  of  FSPS,  a 
number  of  recommendations  are  suggested  below  to  address  deficiencies  in  the  current 
version  of  the  application.  The  recommendations  are  broken  down  into  two  categories: 
current  version  recommended  changes/fixes  and  future  functionality  requirements. 

a.  FSPS  Version  1. 0, 0  Recommended  Changes/Fixes 

1)  Screen  Resolution  Independence.  In  its  current  state,  all  FSPS 
windows  have  a  preset  size.  There  is  no  functionality  for  users  to  resize  the  screens. 
Users  may  only  minimize  screens.  FSPS  windows  display  acceptably  with  a  monitor 
screen  resolution  of  800  x  600  or  greater.  A  screen  resolution  of  at  least  800  x  600  works 
well  with  a  monitor  screen  size  of  at  least  12  inches.  With  a  screen  size  smaller  than  12 
inches,  all  FSPS  windows  automatically  receive  horizontal  and  vertical  scroll  bars. 
While  this  “works,”  it  is  not  optimal  for  users  with  small  screen  computers  such  as  the 
DACT.  For  improved  readability,  it  is  recommended  that  all  screens  within  FSPS  be 
coded  to  automatically  resize  based  on  the  users  particular  screen  resolution. 
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2)  Menu-Bar  Icons.  In  its  current  state,  there  is  a  disconnect 
between  the  parent  form  menu  bar  functions  and  the  child  form  menu  bar  icons.  All 
menu  bar  text  information  resides  on  the  main  “container”  form  while  menu  bar  icons 
reside  on  the  child  forms.  This  is  not  an  optimal  solution  and  is  not  in  keeping  with 
current  “windows  conventions.”  All  child  form  menu  icons  must  be  moved  so  that 
they  reside  on  the  parent  form’s  menu  bar. 

3)  Target  Editor  Consolidation  Screen.  This  screen  allows  the 
FSC  to  search  the  current  list  of  targets  to  determine  whether  or  not  two  or  more 
target  nominations  are  within  a  given  distance  from  one  another  (see  chapter  IV).  The 
current  algorithm  has  a  shortcoming  in  that  it  displays  duplicate  values.  In  other 
words,  if  targets  A  and  B  are  within  1000  meters  of  each  other  than  the  output  display 
shows  both  A  and  B  in  addition  to  B  and  A.  Further,  the  algorithm  is  calculated 
based  on  x  and  y  coordinates  when  the  search  for  duplicates  should  more  accurately 
be  based  on  a  radius. 

4)  Series  Editor  Screen.  The  FSPS  Series  Editor  currently 
displays  all  series  related  information  in  text  boxes  (see  Figure  23).  Created 
manually,  a  series  worksheet  looks  much  more  like  a  spreadsheet.  Figure  32  shows  a 
blank  “Scheduling  Worksheet”  used  to  plan  a  series.  It  is  recommended  that  the 
current  Series  Editor  be  replaced  with  a  spreadsheet  style  editor. 
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Figure  32.  Scheduling  Worksheet. 

5)  Fire  Support  Coordination  Measures  Screen.  The  Fire  Support 


Coordination  Measures  screen  provides  an  ability  for  those  using  the  FSC  Profile  to 
input  a  variety  of  FSCMs.  While  the  functionality  of  this  screen  “works”  it  is  a  poor 
means  for  a  FSC  to  input  these  measures.  FSCM’s  are  most  typically  displayed  as  a 
map  overlay.  The  C2PC  application  already  has  a  map  overlay  creation  capability. 
The  C2PC  overlay  creation  tool  is  the  option  a  FSC  should  use  to  create  all  FSCMs. 
It  is  recommended  that  the  FSCM  functionality  within  FSPS  be  eliminated. 

6)  Help  Files.  In  its  current  state,  the  help  files  are  essentially 
incomplete.  The  framework  has  been  established  to  create  help  files  using 
Microsoft’s  HTML  Help  Workshop  application,  however,  the  content  is  currently 
lacking. 
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b.  Future  FSPS  Functionality 

1)  Transfer  of  FSPS  Files.  FSPS  Version  1.0.0  requires  that  files 
be  transferred  either  as  email  attachments  or  via  FTP.  This  implies  that  an  email  or 
FTP  server  must  be  made  available  on  the  network.  Additionally,  this  adds  more 
tasks  for  the  user,  i.e.  that  user  must  save  the  files  locally,  and  then  open  an  email  or 
FTP  application  to  send  files.  This  is  not  the  optimal  solution.  Ideally,  some  transfer 
capability  should  be  integrated  into  the  FSPS  application.  Users  should  only  have  to 
push  a  “transfer”  button  from  within  FSPS,  add  the  recipient’s  address  and  send  the 
files. 

2)  Target  Overlay  Creation.  FSPS  imports  map  coordinates  from 
C2PC.  This  feature  is  an  integral  part  of  the  target  editing  screens.  However,  to  be 
truly  useful  for  target  planning  purposes,  after  importing  a  grid  coordinate  FSPS 
should  place  a  target  symbol  (a  cross  for  point  targets)  and  the  related  target  number 
onto  the  map  resident  in  C2PC.  Additionally,  when  users  import  their  target  list  after 
receipt  from  the  FSC,  FSPS  should  have  the  ability  to  place  all  the  targets  onto  the 
C2PC  map. 

3)  Interoperability  with  AFATDS  and  BCS.  To  actually 
implement  the  FSPS  application  in  the  Fleet  Marine  Force,  it  must  have  the  ability  to 
exchange  information  with  both  AFATDS  and  BCS.  AFATDS  has  a  robust  database 
that  would  be  useful  to  the  Marine  Corps  at  the  division  level  and  higher  even  if  FSPS 
were  deployed  at  the  regiment  and  below.  Additionally,  the  U.S.  Army  already  uses 
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AFATDS  thereby  creating  a  requirement  for  the  Marine  Corps  to  have  an 
interoperability  capability  to  enable  joint  warfighting.  Moreover,  FSPS  must  have  an 
ability  to  send  targeting  information  to  the  BCS  system  which  computes  technical 
firing  solutions  for  artillery  pieces. 

4)  PosSelectBtn.ocx.  This  is  an  Active  X  component  which  is 
part  of  the  C2PC  application.  The  component  extracts  map  coordinate  information 
from  a  map  resident  in  C2PC  and  imports  it  into  a  text  box.  Though  obtaining  the 
grid  coordinate  is  important,  of  equal  importance  for  computing  a  technical  firing 
solution  is  altitude  information.  It  is  recommended  that  MCTSSA  add  an  Active  X 
component  which  extracts  both  the  grid  coordinate  and  its  associated  altitude. 

B.  FILE  TRANSFER  ANALYSIS 

In  an  attempt  to  demonstrate  the  differences  between  the  data  transfer  rates  and 
throughput  of  the  current  combat  net  radio  (CNR)  and  commercial  wireless  technologies, 
two  networks  were  installed  with  the  assistance  of  Marines  at  MCTSSA.  The  first 
network  utilized  the  SINCGARS  radio  and  the  SP-TCIM,  and  the  other  utilized  Proxim’s 
RangeLAN2  wireless  ethemet  card.  Both  networks  utilized  a  Panasonic  CF-27  hardened 
laptop  computer  as  the  end-user  terminal.  Microsoft’s  NetMeeting  software  was  used  as 
the  file  transfer  program. 
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A  comparison  of  the  time  to  transmit  a  91,364  byte  C2PC  overlay  file  via  wireless 
equipment  with  a  maximum  data  rate  of  2Mbps  is  shown  in  Figure  33  and  the  time  to 
transmit  the  same  file  via  SINCGARS/TCIM  with  a  maximum  data  rate  of  16,000  bps  is 
shown  in  Figure  34. 


Figure  33.  Time  to  Transmit  a  91,364  Byte  C2PC  Overlay  File  Via  Wireless  LAN. 
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Figure  34.  Time  to  Transmit  a  91,364  Byte  C2PC  Overlay  File  Via  SINCGARS/TCIM. 

Additionally,  a  comparison  of  the  time  to  transmit  a  much  smaller  6,192  byte 
FSPS  overlay  file  via  wireless  equipment  with  a  maximum  data  rate  of  2Mbps  is  shown 
in  Figure  35  and  the  time  to  transmit  the  same  file  via  SINCGARS/TCIM  with  a 
maximum  data  rate  of  16,000  bps  is  shown  in  Figure  36. 
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Figure  35.  Time  to  Transmit  6,192  Byte  C2PC  Overlay  File  Via  Wireless  LAN. 
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Figure  36.  Time  to  Transmit  6,192  Byte  C2PC  Overlay  File  Via  SINCGARS/TCIM. 

In  addition  to  analyzing  the  time  to  transmit  a  file,  we  also  looked  at  the 
throughput,  in  bits-per-second  (bps),  of  each  of  the  files.  A  comparison  of  the  throughput 
of  the  91,364  byte  C2PC  overlay  file  via  wireless  equipment  with  a  maximum  data  rate  of 
2Mbps  is  shown  in  Figure  37  and  the  throughput  of  the  same  file  via  SINCGARS/TCIM 
with  a  maximum  data  rate  of  16,000  bps  is  shown  in  Figure  38. 
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Figure  37.  Throughput  of  a  91,364  Byte  C2PC  Overlay  File  Via  Wireless  LAN. 
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Figure  38.  Throughput  of  a  91,364  Byte  C2PC  Overlay  File  Via  SINCGARS/TCIM. 


Additionally,  a  comparison  of  the  throughput  of  the  6,192  byte  C2PC  overlay  file 


via  wireless  equipment  with  a  maximum  data  rate  of  2Mbps  is  shown  in  Figure  39  and 


the  throughput  of  the  same  file  via  SINCGARS/TCIM  with  a  maximum  data  rate  of 
16000  bps  is  shown  in  Figure  40. 
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Figure  39.  Throughput  of  a  6,192  Byte  C2PC  Overlay  File  Via  Wireless  LAN. 
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Figure  40.  Throughput  of  a  6,192  Byte  C2PC  Overlay  File  Via  SINCGARS/TCIM. 

As  can  be  seen  from  Figures  33-40  above,  the  6,192  byte  file  was  transmitted  over 
19  times  faster,  and  the  91,364  byte  file  was  transmitted  over  50  times  faster  via  the 
wireless  network  than  the  CNR  network.  Throughput  was  also  increased  utilizing  the 
wireless  equipment  with  an  increased  throughput  of  27,840  bps  for  the  6,192  byte  file  and 
148,180  bps  for  the  91,364  byte  file.  Although  only  two  files  were  transmitted,  we  found 


the  proof-of-concept  results  very  impressive. 


92 


VL  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  CONCLUSIONS 

The  objective  of  this  thesis  was  to  demonstrate  that  wireless  COTS  technologies 
and  COTS  software  development  tools  can  be  used  to  quickly  enhance  the  ability  of 
today’s  warfighters  to  accomplish  their  mission  and  should  become  the  accepted  practice 
within  the  DoD,  when  feasible,  other  than  exception.  Specifically,  this  thesis  has 
discussed  the  motivation  for  and  the  development  of  a  potential  fire  support  planning 
system  which  could  be  incorporated  to  work  in  conjunction  with  the  Marine  Corps’ 
current  command  and  control  software  application  C2PC.  Additionally,  this  thesis 
discussed  and  analyzed  current  communications  shortfalls  and  offered  potential  wireless 
solutions.  Perhaps  most  importantly  though,  this  thesis  proposed  a  future  methodology 
for  developing  the  majority  of  our  tactical  software. 

B.  ANSWERS  TO  RESEARCH  QUESTIONS 

1.  Can  a  Commercial  Off  The  Shelf  (COTS)  wireless  technology  architecture 
be  implemented  to  increase  the  bandwidth  to  allow  timely  passing  of  data 
intensive  information  at  the  Marine  regiment  level  and  below? 

The  area  of  wireless  networking  is  growing  exponentially  in  the  world  today. 
Many  advances  have  taken  place  in  recent  years  that  makes  the  use  of  wireless 
technologies  within  the  Marine  Corps  very  attractive,  but  based  on  the  results  from  the 
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research  conducted  during  this  thesis,  much  more  research  must  be  done  to  make  it  a  true 
viable  alternative  to  the  current  combat  radio  network. 

2.  Can  COTS  software  developmental  tools  be  used  to  produce  software 

applications  to  aid  the  warfighter? 

As  discussed  in  Chapter  II,  the  RAD  methodology  is  designed  to  take  advantage 
of  off-the-shelf  software  development  tools.  Using  the  RAD  methodology,  Microsoft’s 
Visual  Basic  6.0  and  Microsoft’s  Access  97,  we  were  able  to  build  the  FSPS  application 
in  six  months.  Based  on  the  positive  feedback  from  Marine  artillerymen  currently 
serving  in  the  Fleet  Marine  Force  regarding  FSPS  (see  Chapter  V),  the  authors  believe 
that  COTS  development  tools  and  the  RAD  methodology  of  software  development  are 
not  only  a  viable  means  of  producing  timely,  relevant  software  applications,  but  should 
become  the  standard  practice  for  the  DoD. 

C.  RECOMMENDATIONS 

If  the  Marine  Corps  embraces  C2PC  as  our  tactical  windows  based  command  and 
control  software  application,  then  clearly  we  should  strive  to  add  greater  mission  area 
functionality  to  this  baseline  application.  Our  FSPS  application  demonstrates  that  the 
RAD  methodology  combined  with  COTS  development  tools  are  a  viable  means  of 
meeting  the  needs  of  Marines  in  a  timely  fashion. 

While  there  are  many  individuals  in  academia  working  on  different  areas  such  as 
battery  life,  energy  proficient  protocols,  and  network  routing  to  improve  the  capabilities 
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of  wireless  networks,  we  believe  that  more  emphasis  should  be  placed  within  the  Marine 
Corps  to  bring  these  issues  to  the  standard  setting  bodies  and  commercial  vendors  to 
make  our  unique  requirements  known.  While  MCTSSA  and  MCWL  are  testing  many  of 
the  commercial  vendor’s  products  on  their  own  accord,  we  believe  an  organization  should 
be  designated  to  take  the  lead,  and  be  funded,  to  further  the  research  this  area. 
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